The TEST_() macro

[Phlip]

Newsgroupies:

This sample code tests a WTL dialog box. (Fear not, topic police, we see
little Windows Template Library code here, and the actual TEST_() macro
itself is quite portable.)

I like the TEST_() macro better than the usual Test Suite system (where you
must write extra code to push each Test Case into its Suite's list), so I
wrote a CppUnit clone that uses _only_ the TEST_() macro.

Firstly, all TestCases obey the Abstract Template pattern:

class
TestCase
{
public:
virtual void setUp() {}
virtual void runCase() = 0;
virtual void tearDown() {}
};

Their caller will iterate a polymorphic list of cases, and call setUp(),
runCase(), and tearDown() on each one.

To test a WTL dialog box called ProjectDlg, with a name and address on it,
we write a Suite called TestDialog:

class
TestDialog: public TestCase
{
public:
ProjectDlg m_aDlg;

virtual void setUp()
{ m_aDlg.Create(HWND_TOP); }

virtual void tearDown()
{ m_aDlg.DestroyWindow(); }

TestDialog(): m_aDlg(xml) {}
};

Now we naively derive one concrete class for each of two test cases:

class
TestDialog_first_name: public TestDialog
{
public:
void
runCase()
{
CPPUNIT_ASSERT_EQUAL( "Ignatz",
m_aDlg.getText(IDC_EDIT_FIRST_NAME) );
}
};

class
TestDialog_last_name: public TestDialog
{
public:
void
runCase()
{
CPPUNIT_ASSERT_EQUAL( "Mouse",
m_aDlg.getText(IDC_EDIT_LAST_NAME) );
}
};

Then we get this primordial test rig to pass, using an unrolled version of
the loop we will soon write:

int
main()
{
try {
TestDialog_first_name test1;
test1.setUp();
test1.runCase();
test1.tearDown();

TestDialog_last_name test2;
test2.setUp();
test2.runCase();
test2.tearDown();
}
catch(_com_error & e)
{
guard_(e);
ELIDE_(__asm { int 3 });
return 1;
}
return 0;
}

(Notice, despite I'm using that evil OLE COM ActiveX whatever library from
Microsoft, my code is not full of extra crud like CComBSTR or
CoCreateInstance(). Something chased it all away!)

From here, we need to upgrade TestCase et al to automatically collect the
Test Cases. They should not appear twice - once among the test suites and
again in main(). Removing behavioral duplication tends to improve code's
style.

Make each TestCase instance push itself into a static member list:

#include <list>

class
TestCase
{
public:
typedef std::list<TestCase *> TestCases_t;
TestCases_t static cases;

TestCase() { cases.push_back(this); }
virtual void setUp() {}
virtual void runCase() = 0;
virtual void tearDown() {}
};

TestCase::TestCases_t TestCase::cases;
....
class
TestDialog_last_name: public TestDialog
{
public:
void
runCase()
{
CPPUNIT_ASSERT_EQUAL( "Mouse",
m_aDlg.getText(IDC_EDIT_LAST_NAME) );
}
};
TestDialog_last_name test2;

(Remember that after each few edits all tests must still pass!) Now upgrade
main() to use the list:

int
main()
{
try {
TestCase::TestCases_t::iterator it (TestCase::cases.begin());

for ( ; it != TestCase::cases.end(); ++it )
{
TestCase & aCase = **it;
aCase.setUp();
aCase.runCase();
aCase.tearDown();
}
}

We continue to seek things that look similar, make them the same, and merge
their duplication.

The classes TestDialog_first_name (not shown) and TestDialog_last_name now
look very similar, but so do their object instances. To make them all the
same, we need to declare a class and instantiate an object in one command:

#define TEST_(suite, target) \
struct suite##target: public suite \
{ void runCase(); } \
a##suite##target; \
void suite##target::runCase()

TEST_(TestDialog, first_name)
{
CPPUNIT_ASSERT_EQUAL( "Ignatz",
m_aDlg.getText(IDC_EDIT_FIRST_NAME) );
}

TEST_(TestDialog, last_name)
{
CPPUNIT_ASSERT_EQUAL( "Mouse",
m_aDlg.getText(IDC_EDIT_LAST_NAME) );
}

The object instances went inside the TEST_() macro, which uses
token##pasting to give them unique names. But they all must construct,
globally, so their constructors can register them with the list of cases.

This pattern makes Test Fixtures easy. Classes like TestDialog take care of
setting up and tearing down tested objects, providing a framework to share
other common operations on the tested objects. Test cases are now easy. The
Test Collector pattern ensures when we write new cases, we can't forget to
add them to a remote list of cases.

But these Test Cases no longer look like normal C++ functions!

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces