Re: unit testing C++ code from perl

I owe Noel a review. Naturally, he used my TEST() macro (which I got from
CppUnitLite), but it doesn't have the ability to inherit suites, hence to
setUp or tearDown.

My bad - I didn't see TEST_FIXTURE() yet. The system appears to use a
fixture's constructor and destructor as setUp and tearDown, which has a few
reasons to be the correct idiom in C++.

----8<--------------------------

TDDers:

My former colleagues, Noel Llopis and Charles Nicholson, have
published a nice little C++ test rig, easily competitive with
CppUnitLite. It features the Test Collector pattern via the TEST()
macro, exceptions caught directly in the CHECK*() macros, and a
healthy streaming output system.

It is within a few features of what I always demand of my C++ test
rigs. I severely influenced Noel's shop's prior test rig (uncredited).
So understand, while I have fun, there's a little history involved
here.

* As a cheap shot, the name is wrong. Developer-centric
testing and strict "Unit Testing" is orthogonal.
Sometimes they are the same and sometimes not. The
failure of a Unit Test implicates only one Unit in the
source code. Developers don't need such rigor as they
run their tests over and over again, so failure should
only implicate the most recent edit. All *Units have
this problem...

* the top-level Makefile should have a make test target.

* the README file needs a "getting started" section. The
"examples" are, naturally, the self-tests.

* the Win32 side should use OutputDebugString(), to flow
the test results into the Output panel of a Win32 IDE.

* CHECK*() failure might not invoke a breakpoint. Test
rigs should breakpoint on such errors, with __asm { int
3 } or the equivalent, and then they should present the
option to continue running. This is primarily to ensure
a new test fails for the correct reason.

* The test runner could use a ... progress bar.

* A CHECK*() failure's diagnostic should use the format
"filename:99: error" on GNU, and "filename(99): error"
on Win32, so an IDE can navigate instantly to such
faults.

* The test suite system, TEST_FIXTURE(), might not support
the Abstract Test pattern. That simplifies testing
aspects of the Liskov Substitution Principle.

There's still plenty of good news. For example, CHECK_EQUAL(), despite
being a macro, only evaluates its arguments once. Mine does to, but
Noel and Charles have complete unit tests on all these things.

The code is generally exemplary, with tiny functions, no comments, and
few dependencies. Some test rigs (such as CppUnit) go crazy "coddling"
errors - making formatted lists of them, and such. Pure TDD only needs
instant attention for the most recent errors, and UnitTest++ has only
gentle support for making lists of them.

Noel is the author of /C++ for Game Programmers/, where he comes down
hard on the crufty side of huge C++ projects, including macro abuse. I
wish I could accurately describe his reaction when I first introduced
him to the TEST() macro. It's nice to see he has recovered enough to
promote it!

----8<--------------------------

Someone suggested I post this to their mailing list. I will if my search for
one more specific technical problem succeeds.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!


.

Relevant Pages

  • Re: unit testing C++ code from perl
    ... CppUnitLite), but it doesn't have the ability to inherit suites, hence to ... fixture's constructor and destructor as setUp and tearDown, ... I severely influenced Noel's shop's prior test rig. ... being a macro, ...
    (comp.programming)
  • Re: Could C++ do this without the #pragma
    ... The CppUnitLite macro does something that only a macro can, ... presumably also why it's using a base class with virtual function. ...
    (comp.lang.cpp)