On Thu, Feb 20, 2014 at 06:12:28PM +0100, Jan Gloser wrote: > Earlier this week I wanted to find a C++ testing library. I tried gtest and > cppunit but both of them seemed way too much overkill for my needs.
They might be overkill for your current needs, but what about future needs? As you add more tests, and more complex tests, if you choose either of these you will at least be fairly confident that the functionality will be available, should you need it. If you roll your own, it's almost inevitable that you'll need to extend it over time, and eventually it'll end up getting towards the complexity of these, but probably not done quite as well, since these have had significant use and have been implemented by very good people. I used libcppunit for 9 years in schroot, and switched over to gtest a few months ago. Both are good libraries. gtest is more powerful, and requires less code to do the equivalent tests. I'd recommend it. Both libraries are simple to use for simple tests. Example of simple assertions: https://bitbucket.org/rleigh-debian/schroot/src/33bbfbbce5ae638731527c79068ab40f8da892fb/test/schroot/regex.cc?at=master But then you can move up to using test fixtures: https://bitbucket.org/rleigh-debian/schroot/src/33bbfbbce5ae638731527c79068ab40f8da892fb/test/schroot/keyfile.cc?at=master And then parameterise the tests: https://github.com/rleigh-dundee/bioformats/blob/cpp-formatreader-interface/cpp/test/ome-xml/color.cpp Or specialise based upon type: https://github.com/rleigh-dundee/bioformats/blob/cpp-formatreader-interface/cpp/test/ome-xml/positive-float.cpp https://github.com/rleigh-dundee/bioformats/blob/cpp-formatreader-interface/cpp/test/ome-xml/constrained-numeric.h And other variants are also possible. Unless you have a really good justification for reinventing the wheel, both cppunit and gtest are both pretty good wheels. While both can be complex, they aren't /that/ complex, and you aren't forced to use the more complex functionality if you don't need to. If all you want to do is simple assertions, gtest is about as simple as it gets for this, and the error reporting is really good--it will tell you exactly what failed, including the values, and where, and will also cope with expected and unexpected exceptions. Regarding including your code in Debian, unless it's adding value which the existing solutions don't provide (which I don't think it does), I don't think that in its current form this is suitable. This is not intended to discourage--if you want to write a top-notch C++ testing framework that's really great--but there are many C++ test frameworks already in existence, and it would certainly be worthwhile evaluating the strengths and weaknesses of them before committing to adding yet another. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140220225206.gd11...@codelibre.net
