On Mon, 25 Mar 2013 15:06:46 +0000 (GMT) Bruce Adams <[email protected]> wrote:
BA> I'm very curious what features you feel are missing that make something else like boost.test BA> significantly better There are many things and I probably won't be able to even remember all of them right now but, just off the of my head: 1. You don't need to have classes to write code in C++. So with Boost.Test you can write test functions (although you can organize them in classes too, of course, if you want to but you rarely do because you can have fixtures without classes). In cppunit you have to write test classes and you have to register them with the test suite which adds a lot of boiler plate, especially for simple tests. 2. Partly as a consequence of the above, with Boost.Test you write tests and they run. With cppunit, you add a new test method to an existing test class -- and nothing happens. Because you need to register it separately, of course. So all your test methods must be repeated twice. The above 2 are deep design problems due to copying rigid xUnit approach to a much richer language which is C++ and I don't think they can be fixed without turning cppunit into something that shouldn't have "unit" in its name any more. The rest of the points below probably could be fixed, but I think this is unlikely to happen because, AFAIK, there is no development done on cppunit and also because why would anyone bother considering the existence of many superior alternatives (even if you like xUnit, I think xUnit++ is a better choice than cppunit)? 3. Non fatal assertions, i.e. BOOST_CHECK vs BOOST_REQUIRE. This is just so convenient. With cppunit you basically need to strive to put one test per function to work around their lack. 4. Easy control of the tests you run. It's quite incredible that cppunit doesn't allow you to run individual tests. Of course, you can implement this on top of it (and we did) but how could something like this be not supported out of the box? With Boost.Test you can just specify the tests to run on the command line, as expected. 5. Control of the output. Again, this is something you can do with cppunit but why should you be forced to do it when you should just be able to specify the output verbosity on the command line, as Boost.Test (and everyone else) allows you to do? 6. Test timing. Boost.Test doesn't replace performance non-regression tests but at least it gives you some useful information. cppunit? Not so much. 7. Greater choice of assert macros and easier possibility to specify messages for failing checks (personally I think that all tests should have them). There are more points at http://stackoverflow.com/questions/7922289/googletest-vs-cppunit-the-facts although I don't think Boost.Test has all of them, so it could be unfair to cppunit. OTOH if you look at http://stackoverflow.com/questions/242926/comparison-of-c-unit-test-frameworks you can see that all of Boost.Test, Google test and CATCH have all the features above. And cppunit is probably the only one to have none. Hence my original conclusion: do yourself a favour and choose anything but it. BA> I wonder in that regard it how much it is like boost.build. It absolutely isn't tied to testing Boost. BA> Having seen boost.build in operation I am reasonably impressed but the BA> rest of the world seems to be moving towards cmake. I haven't run BA> across many projects deciding to use bjam. I fully agree that bjam is horrible and CMake is much better. Having said this, I don't believe CMake is ideal neither but I'll leave this for another discussion :-) Regards, VZ
pgpVZ9E6fnZC6.pgp
Description: PGP signature
------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________ soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
