spacer

kevin rutherford's

silk and spinach

 

spacer

CxxTest is different from JUnit

15 Oct 2006

I've been stretching my TDD practice recently by dipping into the murky world of C++ again after a break of a few years. After reading a number of comparisons - notably this one by Noel Llopis - we settled on CxxTest as the project's TDD framework. I then spent a few days converting and refactoring a few existing tests, and writing a load of new ones, to get an initial test suite going.

I discovered one big surprise along the way: unlike JUnit et al, each test suite class is only instantiated once, regardless of how many testXXX() methods it has. This means that the suite's setUp() and tearDown() methods are always acting on the same fixture instance throughout the test run; and the test suite's constructor is only invoked once. So for test independence it's essential to only put pointers into the test's state, so that all test objects can be safely deleted.

Another minor irritation is that CxxTest doesn't easily allow me to run a subset of the tests. This is a useful feature when working with legacy code, because it's sometimes hard to locate a crash among a few hundred tests.

What else should I know about? Are there any other gotchas? Have you found other styles of working with CxxTest?

(Note: CxxTest is also commonly, and mistakenly, known as CxxUnit.)

Filed under: October 2006
Tags: CxxTest spacer JUnit spacer TDD spacer

If you found CxxTest is different from JUnit useful, share it with others:
spacer spacer spacer spacer spacer spacer spacer spacer

spacer

cosmos

 

» see links to this post on technorati
» see links to this post on Google blogsearch

The trackback URI for this post is silkandspinach.net/cgi-bin/mt/bananas.cgi/290 (although it rarely, if ever, seems to work).

spacer

comments

 

Martin Ankerl (15 Oct 06, 14:37)

Hi! We've been using CxxTest for quite a while, and are pretty happy with it. We have integrated cxxtest as a post-build step in Visual Studio. When you use
--runner=ParenPrinter you can doubleclick an error message to jump directly to the problematic sourcecode. The build fails if the tests are not run successful.

The post-build event calls nmake with a Makefile, that contains a variable TESTS which defaults to Test*.h, so that all Tests are included. In case of a bug I modify the Makefile to include just the problematic file so that tests are run more quickly.

david carlton (16 Oct 06, 05:03)

It's too late for you now, I suppose, but I will immodestly suggest my framework, at <unittest.red-bean.com/>. Its main distinction from other C++ test frameworks out there is that it doesn't have setUp and tearDown functions: it uses the test class's constructor and destructor instead. Also (because of C++'s lack of reflection) it represents tests by classes instead of by member functions. So if you want a bunch of tests to all, say, set themselves up and tear themselves down in the same way, just have them inherit from the same base class. (And individual tests can tweak that further by sticking more stuff in their constructors/destructors.)

We've been using it for a little more than three years at work now; it does the job for us. And it avoids the weirdnesses that you mention. It does allow you to run a subset of the tests, too, though if you want to locate a crash, it installs a signal handler that will tell you the test that was running at the time.

(You don't allow much in the way of HTML in comments here, do you? No links, no paragraphs...)

Kevin (17 Oct 06, 13:37)

Hi Martin, I use --runner=ParenPrinter too, with the tests set up as an external tool. So we have to run them manually after each build. I like the idea of the nmake job as a post-build step - as you say, it moves the test suite configuration into an editable file, instead of being hidden in the project properties as I have it now. Actually I have the tests stored in a separate project which builds only if the product's build succeeded - I'm sure I can extend it to run the tests too. Thanks for the tip!

Kevin (17 Oct 06, 13:43)

Hi David, I'll certainly take a look at red-bean - thanks for the link!

(I receive so many spam comments that I've been close to disabling them altogether. I'll re-enable HTML now and see what happens...)

do you have a comment on this article?

(required)
(required)

Basic HTML formatting tags allowed, eg. <p>, <strong>, <blockquote> etc...

 
gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.