Boost logo

Boost :

Subject: Re: [boost] What Should we do About Boost.Test?
From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2012-10-04 04:30:23

> Sohail Somani <sohail <at>> writes:

> I looked at the example and I couldn't really understand it. However,
> here are the reasons I prefer Google Mock to writing my own mocks over
> and over:
> 1. The psychological barrier of creating yet-another-class. Maybe this
> is PTSD from that one time I had to use Java or something.

Don't you need to specify mock class? WE can probably improve Boost.Test's
macros to have similar amount of typing as what gmock would require, but
difference is not that big as it is, while IMO we Boost.Test have is more

> 2. The main things in my mock tests that change are the values, not the
> types.

I do not understand this.
> Google Mock makes it easy for me to write quick tests for when values
> change:
> MockThingy mock;
> EXPECT_CALL(mock,something(100))
> .WillOnce(Return(32));
> The above will take a *generic* mocked class and give it behaviour. This
> particular test expects a call to the "something" function with a
> parameter of 100 and will return 32 once.

Are you saying you do not need to write MockThingy ahead of time and
miraculously you can write mock.something(100) somewhere below? Somehow I do not
believe it.

More over, what if you need to test 10 different, but similar scenarios in 10
different test cases. Now each one of them will have to spell out above
EXPECT_CALL... (probably because it is common part). I'd rather spell it out
once in MockThingy definition or even better does not spell it at all. Instead I
just write mock.something(100); and that's it. No expectation needs to spelled
out in test case with Boost.Test approach.

> The important thing is that I can re-use the mocked class for other

What to reuse? So you did write it once, right?

> tests as well. I can't immediately see how this is possible with the
> example you have shown.

What stopping you to reuse mock classes from my example?


Boost list run by bdawes at, gregod at, cpdaniel at, john at