how to turn off a unit test in CPPUnit

Question

I (finally) have my app being unit tested with CPPUnit and I have CruiseControl.NET running the tests and displaying the test output. I have several tests that always fail, however, so CruiseControl always marks the build as failed. Is there any way I can "turn off" or "skip" or "ignore" these always-failing tests? I'd rather not just comment them out in the source, since they're pointing out valid errors in the app that we can't fix for business reasons at present, but may be able to address in a future release. If possible, I'd like to be able to still run the tests and see their output, but just have CPPUnit not count them as failed (or maybe even ignore them at the CruiseControl level).

Answer 1

G'day,

Aren't you able to comment out the individual tests in the testSuite_* code?

Edit: Sorry, I didn't fully parse your question. But a testSuite_ is a way of grouping individual tests that are related in some way, e.g. for an LD_PRELOAD remapping library that we're using we have several test suites, e.g.

testSuite_access.c
testSuite_acl.c
testSuite_chdir.c
testSuite_chmod.c
...    
etc.

that group several tests together that exercise that particular OS command.

But having a think about it, and actually reading what you said (-: , you seem to want to keep the functionality of CPPUnit working and not play with it, i.e. still flagging tests as failing.

So I'd suggest looking at playing with the behaviour of CruiseControl to ignore those known failures. Maybe even flag them as "acceptable" for the time being, e.g. an amber status for the build rather than a green or red status both of which are false for the circumstances you describe.

CruiseControl is very configurable and there is an active community for it over at their wiki which is accessible via their home page.

HTH

Sorry I can't be more specific apart from recommending that you modify CruiseControl behaviour rather than play with CPPUnit.

Answer 2

As demonstrated in the cppunit cookbook, you can organize your tests into test suites. I would put the "known to fail" tests in a separate test suite. You can then chose when to run this test suite and when to ignore it.