Exploring the C++ Unit Testing Framework Jungle over on Games from Within is a really good look at all of the C++ unit testing frameworks out there. It compares the following frameworks:
CppUnit
Boost.Test
CppUnitLite
NanoCppUnit
Unit++
CxxTest
I’m one of those people who has written their own mini framework because none of the existing frameworks seemed to do what I wanted at the time I needed the framework and I wanted to get up to speed quickly with minimal learning time.
I’m glad that Brian Button went to the trouble of writing this post and thinking through the implications of shared setup and teardown code in tests. I’ve been a bit concerned about some of my tests for a while now. You see, I don’t use a fancy framework, I just write them myself in C++ and generally there isn’t much shared setup code because I don’t find it that useful. Brian’s insight that the duplication present in tests is often a good thing because it allows the test to communicate more clearly is pretty much what I’ve thought for a while.
Simon is thinking about using unit testing to help with performance testing. Whilst I’ve found it useful to use unit tests as very focussed ways to run a profiler on a selection of code I don’t think it’s a good idea to tie the success of your test to it completing within a particular length of time.
After all, you might decide to run all of your tests under a tool such as Boundschecker and it would be a pity to get false failures due to the fact that the test is running slower just because you’re using some other tool or running on some other machine.
I’ve just started work on an ISO8583 server for a client. I’ve done similar work for them in the past and the first thing that I did was to take the basic shell of the last server that I did for them and update it to use all of latest version of The Server Framework. The next was to start to look at the first of the requirements for the new server.
Last week I posted an entry about the simple, hand built, mocks that I use for testing in C++. Whilst I stand by my previous assertion that writing the mocks yourself gives you an further insight into your design from a client perspective I think the discussion that I had with Roy Osherove after last week’s posting has made me appreciate the power of having mocks that support the programmatic specification of ’expected’ behaviour.
My Unicode Byte Order Mark hassles yesterday were brought to light by one of my mock objects. It was the expected output log for the object that had been converted from UTF-16 to UTF-8 by CVS without asking… Whilst writing that piece I realised that I probably needed to write this piece. You see, I spend most of my time in C++ and I write most of my Mock objects myself rather than having some framework do it for me and something that I found very useful and simple is the idea that my mock objects create simple logs of what happens to them.
A long time ago, on Practical Testing: I mentioned that there was a small chance that the way that ResetTimer() operated could mean that you could pass in a handle that you no longer owned and affect someone else’s timer by mistake; I said it was unlikely to cause problems… In this posting we fix this problem and in the process show how TDD builds up a set of tests that can support you during redesign…
Roy Osherove links to Mockpp a mock object framework for C++ and comments on how the framework is painful to use (and it looks like it was painful to write…) He concludes that he’s getting on just fine writing his mocks manually… In my experience you’d miss a lot of very useful learning and design work if you didn’t write the mocks manually…
If you’re using a mock object to help you test a piece of code that’s under development, that is, you’re doing TDD or something close, then the act of creating the mock is useful for the design work that you’re doing by doing TDD… Using a framework to create your mocks for you means that you don’t get to experience as much of the “being a client of your own code” experience as you might otherwise, therefore it’s something to avoid; IMHO…
A while ago I mentioned how I had hoisted a mock object up into production code because it only needed a few changes to make it usable as real code rather than just test code. This last week we’ve done this again…
Our system was designed with testing in mind; we’re loosely coupled and, consequently, have lots of interfaces that we can implement any way we want. To allow us to test large chunks of the system together we deliberately plugged the external data sources in right at the top.
We’re almost at the end of our hand over phase now; my time on the project is almost over. The last couple of weeks have been interesting. We’ve been working towards a demo of the system and this seems to have helped to get everyone moving in the same direction; suddenly the hand over seems to be happening… I don’t think I’ll need to be that involved in the demo as everyone else knows what’s going on and can explain how the system works… This is a Good Thing.
