Lesson: Don’t use InSequence unless you have a really good reason to do so.

It is obvious that requiring mock calls to be in a particular order leads to fragile tests.  I can deal with that.  What may not be so obvious, is that the tests may fail in ways which don’t immediately lead you to deduce what caused the failure.

I added a new mock class and a new EXPECT_CALL, and didn’t notice that it fell after an InSequence meant to govern calls on a different mock.  The code segfaulted with:

Unexpected mock function call - returning default value. Function call: getFoo() The mock function has no default action set, and its return type has no default value set.

I could clearly see that I was setting the default action.  As this was the first test in the suite and the tests stopped cold on the segfault, I couldn’t see the reason it didn’t think there was a return value specified.  It wasn’t until I reordered the tests and started comparing a test that worked line by line with the test that failed that I discovered the issue.

By that time I was already stressed out, something unit tests are supposed to alleviate, not cause.  Of course, it would have been nice if google mock would have indicated an out of order mock call, instead of this failure.  I’m not sure how difficult that would be to fix.

In the mean time, I may shy away from InSequence and it ilk.  But, I will still be using google mock. Hopefully I will continue to post tidbits I learn as I delve futher into unit testing, TDD and mocks.