Hi,
I take your points but just for the record a number of the items listed on:
http://stackoverflow.com/questions/7922289/googletest-vs-cppunit-the-facts
are easily doable in cppunit. i.e. exceptions and adding information.
Others are not provided out of the box but doable as write once solutions.
The reason for having to register each test is, as you allude to, a consequence
of porting from java.
junit avoids the boilerplate by using reflection and the original porters did
not provide an alternative.
There are some features which are of low utility. For example, "test shuffling".
The big thing for me would be it ceasing to be actively maintained.
Still you have piqued my interest enough to want to do a more thorough review
of the options now available
and where they stand with respect to each other when I get time.
I'm with you on cmake. Its like democracy, there must be a better system but we
haven't found it yet.
Regards,
Bruce.
>________________________________
> From: Vadim Zeitlin <[email protected]>
>To: SOCI general discussion list <[email protected]>
>Sent: Monday, March 25, 2013 3:26 PM
>Subject: Re: [soci-users] Using a unit testing framework?
>
>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
>
>------------------------------------------------------------------------------
>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
>
>
>
------------------------------------------------------------------------------
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
