系统原型

前言

    阅读源代码并不是一件轻松的事情，在我们一头扎进代码的汪洋大海之前，我们首先要对问题本身有一个直观的认识。搭建系统原型就是一个很好的方法。

从简单到复杂

    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。