Sohail Somani <sohail <at> taggedtype.net> 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 flexible.
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? Gennadiy