Hi all, I'm the author of Opmock and would like to answer to Philip Stuyck review, as I believe it's a bit unfair. Philip, you could have used the wiki for posting lengthy remarks like these one, and I would have answered with a more appropriate tool.
point 1 : all your remarks are about the unit testing part of Opmock. As its name suggests, opmock is primarily a mocking tool. It comes also with a minimal unit testing framework, but you are free to use any unit testing framework you want. It's described in the documentation : have you read it?
point 2 : fixtures. Not offering fixtures is a *design choice*. Again, the *why* is described in the documentation, but long story made short, if you use fixtures, then all your tests are made dependent on a single precondition : this violate the idea of small, independent tests that run in total isolation. beside this, there's actually a 'hidden' feature in opmock to add fixtures (pre and post conditions for unit tests are registered this way if you use the unit testing functionality). If you read the generated code you'll find out how to add your how functions to run before/after a test.
point 3 : custom error message for assertions. I don't see the point of this. If your test is small enough, then the line number and displaying the expected and actual value is enough to find the problem. if it's not the case, you should ask yourself if your test is really a unit test, or just an automated functional test.
As a conclusion : all your rants are focused on the unit testing part, which is a very minimal part of the tool. You could go on and on with "defaults" like no memory allocation (design choice for embedded development, and it was actually *harder* than using malloc or new), not forking for each test (design choice for portability)...
It's very easy to combine opmock with feature complete unit testing framework, like google test, if you want to, and you know it, as people doing this, that we both know, *work* in your company.
Finally, Google test/Google Mock/CppUnit/whatever are also pretty much a single man project. Just have a look to the commit notice. If the tool does the work, is not too buggy, why bothering about the team size?