Opmock is a mocking and testing tool for C and C++. It is useful if one wants to implement micro testing and TDD in a similar way of what exists in Java or C#. It is designed with legacy code in mind, and should work with all C++ and C compilers.
NEW : version 2.1 is out. Currently there are no binaries to download, please checkout the code from svn and compile from the sources.
You can checkout version 2.1 with the command:
svn checkout svn://svn.code.sf.net/p/opmock/code/tags/opmock2.1 opmock-code
Then read the updated docs in /documentation. Or just download the docs, read them and compile.
The current version is 2.1. This is a full rewrite of the 0.9x series. The 0.9x is still maintained for bug fixes, but new functionalities will go only in the 2.0 branch.
Have a look to the blog, the wiki and the download page for more information.
I used this tool to generate stub/mock files and it was very easy to use. I surfed around and tried some other tools but it was always some problem with them. But opmock2 actually worked out of the box.
Opmock lacks a lot of functionality which is really needed when writing maintainable unit tests. I really miss the notion of a fixture and the ability to register a setup and teardown method that is supposed to run before and after each unit test. Assert statements with the ability to provide a custom error message is also missing, the user running the unit tests easily sees what is wrong. A small gui with filtering is also appropriate, the output is spawn to the console and when running many tests one might have to scroll several screens before the actual error is readable. All in all what is provided is pretty basic, with a little effort the caveats I mention here can be solved. But I am wondering if it is really worth your while to invest your time in it to: - keep maintaining it, clearly a one man job - use it, compared to other frameworks it looks a bit too minimal to me. answer Pascal reply of 2011 ;-) My comments were based on my experience with unit testing in other frameworks and based on some reading : the art of unit testing. My comments are correct, I still stand by them and are meant as positive criticism. I also used the wiki. Did you read it ? Fixtures are present in nearly all frameworks and are usefull. If it is a design choice not to support it, it is a poor design choice. I find myself doing workarounds this missing feature. Clear error messages are key for anyone having to look at the output of unit tests. The more to the point the better. If you look into this point alone. It is extremely easy to implement. Actually the small this framework might be, I found that this framework was indeed easy to learn and use. So, I'd like to see it improved furhter. But I was really wondering if this is worth it, being a one man job. Apparently the same is true for some other frameworks. not nunit anyway ;-) The value of a project like this, and it's success will be a matter of how much effort is continuously spent in it.
great app, works nicely
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?