前言
阅读源代码并不是一件轻松的事情，在我们一头扎进代码的汪洋大海之前，我们首先要对问题本身有一个直观的认识。搭建系统原型就是一个很好的方法。
从简单到复杂
cppunit要解决的问题是如何进行单元测试？那么到底该如何用C++代码实现单元测试呢？我们先从最简单的问题开始讨论。最简单的测试代码应该是这个样子：
实现代码：
void testFun(){ assert(1 != 2);} 调用代码：
testFun();
够简单吧，简单得都有点无聊了，可是结论却很有意义：“最简单的测试就是一个测试函数。”由此出发，我们很快就想到了，再复杂点的测试就应该是一个测试类了吧：
实现代码：
class TestClass{public: void startTest() { } void test1() { assert(1 != 2); } void test2() { assert(2 != 3); } void test3() { assert(3 != 4); } void endTest() { }}; 
调用代码：
TestClass testClass;testClass.startTest();testClass.test1();testClass.test2();testClass.test3();testClass.endTest();
还不错吧，我们用一个类把一些相关的测试函数组织起来，并且还可以加入公共资源创建和清除的功能。套用一个测试中的专业术语，一个测试类实际上对应了一个测试用例。
但是我们知道，真正搞测试时可不是仅仅有一个测试用例，而应该有一组测试用例。所以我们最好还是把测试用例再组织一下，一组测试用例对应一个测试包。更进一步，一个测试包里是不是还可以包含测试包？这个想法很合理，由此，我们就得到了一个测试用例的树形结构，你可以为任何一个树节点命名，指定执行任何一个树形分支。很酷的功能吧，不过到底该如何实现呢？实现这种无限嵌套的树形结构，程序员们是有前人的宝贵经验可以借鉴的：设计模式中的composite模式。
实现代码：
class Test{public: virtual ~Test() {} virtual void run() = 0; virtual void addTest(Test* test) = 0;};class TestCase : public Test{public: void run() { } void addTest(Test* test) { }};class TestSuite : public TestCase{public: ~TestSuite() { for (int i = 0; i < tests.size(); i++) { delete tests[i]; } } void run() { for (int i = 0; i < tests.size(); i++) { Test* test = tests[i]; test->run(); } } void addTest(Test* test) { tests.push_back(test); }private: std::vector tests;};
调用代码：
TestSuite suite;TestCase* testCase = new TestCase;suite.addTest(testCase);suite.run();
实际的结构
CppUnit实际的结构和原型稍微有点不同，见下面的类图：
作为比较，下面给出composite模式的类图，以加深印象：
可以看到CppUnit的类图和composite模式的类图基本上是一致的，除了TestSuite类多派生了一层以外。那么，这样做有什么好处？请注意，TestComposite类中并没有add方法，反倒是TestSuite中有一个addTest方法，这种设计弱化了TestComposite在composite模式中的作用，同时也强化了TestSuite类的地位，估计这是为了即展示标准的composite模式，同时也突出了测试包这个专有概念而专门设计的，也算是对composite模式的独特理解。
完整的结构
上面的类图并不完整，CppUnit中关于测试用例，测试包的类图远比上面的类图要复杂，但是核心的思想确实就是composite模式。下面给出完整的类图：
这个完整的类图增加了很多东西，下面依次介绍一下：
TestPath
既然我们的测试包是可以无限嵌套的目录结构，这个TestPath就类似于全路径之类的东西了
TestFixture
前面我们说过，CppUnit中的一个测试用例就是封装了一组相关测试函数的测试类，这个测试类还可以加入公共资源创建和清除的功能，这就是setUp和tearDown两个函数的含义。CppUnit把这部分功能提取出来了，封装为TestFixture，实际上用户自定义的测试函数也是挂在这里的，实际上就是下面的那个ExampleTestCase。CppUnit把TestFixture和TestLeaf两个类并列了，你可以把这理解成前者是测试类的静态部分，后者是测试类的动态运行（run）部分。这样的设计是为了使用户自定义测试用例更容易一点，一般情况下，你只需要从TestFixture类派生自己的测试类就可以了，根本无需关心TestLeaf的存在。
TestCase
这就是前面说过的测试用例，它同时派生于TestFixture和TestLeaf，即包括了setUp和tearDown两个函数，也包括了run函数。它应该是CppUnit中最基础的单元了，要实现自己的测试用例类，最直接的方法就是从这个类派生，但是刚才也说过了，从这里派生足够的通用，也足够的强大，却未必简单。
TestCaller
这是一个模板类，它同时派生于TestCase，同时又聚合了一个ExampleTestCase类，它实际上这是一个辅助类。上面说过你只需要从TestFixture类派生自己的测试类就可以了，根本无需关心TestLeaf，TestCase的存在，就是因为有这个模板类才实现的 ，关于详细细节，我们将在下一章讨论。
TestRunner
这也是一个辅助类，它的run函数有两个参数，这让我们可以选择嵌套测试包的任一个分支。这个类的内部组合了一个从TestSuite派生的简单的包装类WrappingSuite。
