Last Thursday was my first time at London’s C++ UGM. This is a fairly small and young group. It looks like it has only just been going (maybe four or five meetups so far). Having said that, the topics are obviously very relevant to me (and everyone at work) so I’m going to try and cajole some more people into going. Also: I’m sick and tired of being dominated by a crowd of Java programmers or web/mobile guys wherever I go. C++ can do cool stuff too (yes – honestly it can!).
The talk itself was about a testing framework called Catch originally developed by Phil Nash. TDD seems to be very much a hot topic at the moment in software circles. A large part of the change towards TDD is cultural. This means discussions about changing behaviour, processes are quite important, buy-in from product owners etc.
HOWEVER, that is not to say that the technical side of it is unimportant and unit testing in C++ still feels a little awkward to me. So new ideas in a new testing framework are definitely welcome. (Though there is hardly a dearth of frameworks out there….)
And interesting and good ideas this framework definitely has. I’ll just quickly go through the ones I picked up during the talk in bullet points (I haven’t actually tried it yet, so can’t actually share my own experience):
- It seems to be really lightweight and easy to get started. All it needs is an include of a single header and a #define in one file so that it generates the main for you.
- I really like the way that test asserts work. Instead of the standard EXPECT_EQ(actual, expected) (<—- Google syntax) where you are never sure which one was actual and which one was expected, it uses style similar to normal asserts i.e. REQUIRE(add(3,1) == 4). I also like the output this produces when this test fails: There is some very clever template matching going on here to produce both the actual numerical values as well as the original line of code triggering the failure.
- Instead of fixtures, it introduces sections. These are ways of splitting one test into several sub-sections, all of which will be run (and set up) independently. While it is quite heavy on macros, this gives the test case code a nice coherent feel.
- It works particularly well when used in conjunction with the “given when then” framework for setting up your test cases. It looks like this makes it very easy to express the intention of a test case beyond just using the name of the test case. Since this is one of the biggest challenges in reading/interpreting tests, anything which helps here is particularly welcome!
Altogether some interesting stuff here. I’ll definitely give Catch a shot for some of my projects at home and will report back after.