如何将诸多技术综合运用到一个实际的framework中来，笔者以为，CppUnit为我们提供了一个难易适中的参考范例。这应该是一个很好的例子，因 为它不甚复杂，却汇聚了一个framework所必需的某些设计思想以及实现技巧。在这里，我们可以看到STL的实际使用（包括一些简单的traits技 法），Design Pattern的灵活运用（比如：Composite，Factory，Decorator，Singleton，Observer等）。

当然，也应该指出，由于CppUnit还在不断改进中，其代码中未免还有“败笔”及不尽如人意之处。但是，瑕不掩瑜，并且从中我们也可以感受到一个成熟框 架的演进过程。

由于有过一点framework的设计经验和体会，笔者在阅读CppUnit源码的过程中，时常能有共鸣，并且对于框架的设计者在某些细节的处理方法，也 深以为然，偶尔也有“英雄所见略同”的感叹。希望可以通过笔者的讲解，使大家也能够同样有亲历之感。

CppUnit是xUnit系列中的c++实现版本，它是从JUnit移植过来的，第一个移植版本由Michael Feathers完成，相关信息可以在http://www.xprogramming.com/software.htm找 到。它是操作系统相关的，随后，Jerome Lacoste将之移植到了Unix/Solaris，在上述连接中也能找到该版本的相关信息。CppUnit项目就是基于这些版本建立起来的。有关 CppUnit的讨论可以在http://c2.com/cgi/wiki?CppUnit找 到，在那里你还可以找到CppUnit先前的版本以及许多其它操作系统环境下的移植版本。这个库受GNU LGPL（Lesser General Public License）的保护。作者包括：Eric Sommerlade (sommerlade@gmx.net)，Michael Feathers (mfeathers@objectmentor.com)，Jerome Lacoste (lacostej@altern.org)，J.E. Hoffmann ，Baptiste Lepilleur ，Bastiaan Bakker ，Steve Robbins

作为一个完整的CppUnit framework，虽然源码所在的实际路径可能不尽相关，但从逻辑上讲它们被划为如下几个部分：

• core：CppUnit的核心部分
• output：掌管结果输出
• helper：一些辅助类
• extension：作为单元测试的延伸，对CppUnit core部分的扩展（比如：常规测试，重复测试）
• listener：监视测试进程和测试结果
• textui：一个运行单元测试的文本环境
• portability：提供针对不同平台的移植设置

上述所有的内容均被置于CppUnit名字空间之内。

• 本文主要内容依据CppUnit源码而来，部分内容还来自于源码自身所附的注释、ChangeLog等
• 本文只作源码解读，至于xUnit家族的相关背景及基本知识笔者不准备叙述，读者可以参看相关文章
• 对于文中所涉及的Design Pattern，Refactoring，STL等相关知识，请读者参看相关资料。
• 除了文章本身，文中所列源码，也夹带了morning的一些注释，用以进一步说明代码意图，注释中方括号内为morning的疑问
• 为了节省篇幅、简化内容、突出主题，文中未列出全部代码，而是有选择的给出部分代码

在CppUnit中，有一个贯穿始终的最基本的pattern，那便是Composite Pattern。在GoF中对该pattern有如下描述：将对象组合成树形结构以表示“部分-整体”的层次结构。Composite使得用户对单个对象 和组合对象的使用具有一致性。在CppUnit的框架中，测试类分为两种，某些测试类代表单个测试，比如稍后讲到的TestCase（测试用例），另一些 则由若干测试类共同构成，比如稍后讲到的TestSuite（测试包）。彼此相关的TestCase共同构成一个TestSuite，而 TestSuite也可以嵌套包含。两者分别对应Composite Pattern中的Leaf和Composite。

相关文件：Test.h

这是所有测试类的抽象基类，规定了所有测试类都应该具有的行为，对应于Composite Pattern中的Component，除了标准的virtual dtor外，还定义了四个纯虚函数：

    // 运行测试内容，并利用传入其内的TestResult搜集测试结果，类似Component的Operation操作
    virtual void run (TestResult *result) = 0;
 
    // 返回当前包含的测试对象的个数，若为TestCase，则返回1。
    virtual int countTestCases () const = 0;
 
    // 返回测试的名称，每个测试都有一个名称，就像是标识，用以查找或显示
    virtual std::string getName () const = 0;
 
    // 本测试的简短描述，用于调试输出。
    // 对测试的描述除了名称外，可能还有其他信息，
    // 比如：一个名为“complex_add”的测试包可能被描述成“suite complex_add”
    virtual std::string toString () const = 0;

相关文件：TestFixture.h

该类也是抽象类，用于包装测试类使之具有setUp方法和tearDown方法。利用它，可以为一组相关的测试提供运行所需的公用环境（即所谓的 fixture）。要实现这一目的，你需要：

• 从TestFixture派生一个子类（事实上，一般的做法是从TestCase派生，这样比较方便，具体见后）
• 定义实例变量（instance variables）以形成fixture
• 重载setUp初始化fixture的状态
• 重载tearDown在测试结束后作资源回收工作

此外，作为完整的测试类，还要定义一些执行具体测试任务的测试方法，然后使用TestCaller进行测试。关于TestCaller，在helper部 分将会讲到。

因为每个测试对象运行在其自身的fixture中，所以测试对象之间不会有副作用（side effects），而测试对象内部的测试方法则共同使用同一个fixture。

来看一下TestFixture的定义，除了标准的virtual dtor外，还定义了两个纯虚函数：

// 在运行测试之前设置其上下文，即fixture
// 一般而言setUp更为重要些，除非实例变量创建于heap中，否则其资源的回收就无需手工处理了
virtual void setUp() {};
 
// 在测试运行结束之后进行资源回收
virtual void tearDown() {};

相关文件：TestCase.h，TestCase.cpp

派生自Test和TestFixture（多重继承），兼具两者特性，用于实现一个简单的测试用例。你所要做的就是派生该类，并重载runTest方法。 不过通常你不必如此，而是使用TestCaller结合TestFixture的方法，这样很方便。当你发现TestCaller无法满足，你需要重写一 个功能近似的类时，再使用TestCase也不迟。关于TestCaller，在helper部分将会讲到。

TestCase中最重要的方法是run方法，来看一下代码，并请留意注释：

void TestCase::run( TestResult *result )
{
  // 不必关心startTest的具体行为，在讲到TestResult时自然会明白
  // 末尾的endTest亦是如此
  result->startTest(this);
 
  try {
    // 设置fixture，具体内容需留待派生类解决
    // 可能有异常抛出，处理方式见后
    setUp();
 
    // runTest具有protected属性，是真正执行测试的函数
    // 但具体行为需留待派生类解决
    try {
      runTest();
    }
    // 在运行测试时可能会抛出异常，以下是异常处理
    catch ( Exception &e ) {
      // Prototype  Pattern的一个应用
      // e是临时对象，addFailure调用之后即被销毁，所以需要创建一个副本
      Exception *copy = e.clone();
      result->addFailure( this, copy );
    }
    catch ( std::exception &e ) {
      // 异常处理的常用方法——转意
      result->addError( this, new Exception( e.what() ) );
    }
    catch (...) {
      // 截获其余未知异常，一网打尽
      Exception *e = new Exception( "caught unknown exception" );
      result->addError( this, e );
    }
 
    // 资源回收
    try {
      tearDown();
    }
    catch (...) {
      result->addError( this, new Exception( "tearDown() failed" ) );
    }
  } 
  catch (...) {
    result->addError( this, new Exception( "setUp() failed" ) );
  }
 
  result->endTest( this );
}

可以看到，run方法定义了一个测试类运行的基本行为及其顺序：

• setUp：准备
• runTest：开始
• tearDown：结束

而TestCase作为抽象类无法确定测试的具体行为，因此需要留待派生类解决，这就是Template Method Pattern。事实上，该pattern在framework中是很常见的。因此一个完整测试的简单执行方法是，从TestCase派生一个类，重载相 关方法，并直接调用run方法（正如TestFixture中所提到的）。

有意思的是，TestCase中还有run的另一个版本，它没有形参，而是创建一个缺省的 TestResult，然后调用前述run方法。不过好像没怎么用到，大概是先前调试时未及清理的垃圾代码，也难怪会有“FIXME: what is this for?”这样的注释了。

TestCase有两个ctor：

TestCase( std::string Name );        // 测试类的名称
TestCase();

后者主要用于TestCaller，因为在使用TestCaller时，需要一个default ctor

此外，TestCase将copy ctor和operator=声明为private属性，以防止误用。

相关文件：TestSuite.h，TestSuite.cpp

一组相互关联的测试用例，构成了一个测试包，这就是TestSuite，也就是Composite Pattern中的Composite。和TestCase一样，也派生自Test，只是没有fixture特性。除了测试类的名称外，在 TestSuite中还维护了一个测试对象数组，它被声明为private属性：

std::vector<Test *> m_tests;
const std::string m_name;

来看一下TestSuite的run方法是如何实现的，并请留意morning的注释：

void TestSuite::run( TestResult *result )
{
  // 遍历vector<Test *>
  for ( std::vector<Test *>::iterator it = m_tests.begin();
        it != m_tests.end();
        ++it )
  {
    // 可能中途终止
    if ( result->shouldStop() )
      break;
 
    Test *test = *it;
    // 调用每个test自己的run
    // 可能是TestCase实例，也可能是TestSuite实例，
    // 后者形成递归，但此处却全然不知
    test->run( result );
  }
}

关于TestResult及其shouldStop方法，稍后会讲到。不过此处的break，到也算是活用 Composite Pattern的一个简单范例。从效率的角度考虑，当确信不必再执行后续的test时，即可直接返回，而不是照葫芦画瓢，简单的调用一下test的run 方法。

既然TestResult派生自Test，那么countTestCases又是如何实现的呢：

int TestSuite::countTestCases() const
{
  int count = 0;
 
  // 遍历vector<Test *>
  for ( std::vector<Test *>::const_iterator it = m_tests.begin();
        it != m_tests.end();
        ++it )
    count += (*it)->countTestCases();   // 递归调用每个test的countTestCases，并累加
  return count;
}

至于addTest，自然是不能少的，它对应于Composite的Add方法：

void TestSuite::addTest( Test *test )
{
  m_tests.push_back( test );   // 将test添加到测试对象数组的尾端
}

不过请注意，addTest方法并未出现于抽象类Test中，关于这类设计上的权衡在GoF中，Composite Pattern一节有专门的论述。

TestSuite管理着其下所属诸测试对象的生命周期，在dtor中，它会调用deleteContents方法：

void TestSuite::deleteContents()
{
  for ( std::vector<Test *>::iterator it = m_tests.begin();
        it != m_tests.end();
        ++it)
    delete *it;
  m_tests.clear();
}

此外，TestSuite还为外部访问其所属测试对象提供了接口，因为返回值是const &类型的，所以是read-only的：

const std::vector<Test *> &getTests() const;

从这里开始，将要讲述core中，测试结果记录的相关部分。

CppUnit是支持多线程的，你可以在一个线程中执行测试，在另一个线程中收集测试结果；或者在不同线程中并行执行多个测试，而用一个线程收集测试结 果。framework中为此提供了简单而必要的支持。

相关文件：SynchronizedObject.h，SynchronizedObject.cpp

SynchronizedObject用来管理一个被同步对象，前面提到的TestResult就是从该类派生的。所谓被同步对象，是指其成员会被多个线 程并发使用。

SynchronizedObject定义了一个public属性的abstract inner class——SynchronizationObject，代表具备同步属性的对象：

class SynchronizationObject
{
  public:
    SynchronizationObject() {}
    virtual ~SynchronizationObject() {}
    virtual void lock() {}
    virtual void unlock() {}
};

此类定义了互斥锁功能，但具体行为需在其派生类中实现。不同环境下的实现方式想必也不尽相同。随CppUnit源码所附的范例中有个 MfcSynchronizationObject就是SynchronizationObject的子类，它使用了MFC的 CCriticalSection：

class MfcSynchronizationObject
    : public CppUnit::SynchronizedObject::SynchronizationObject
{
  CCriticalSection m_syncObject;
public:
  void lock()
  {
    m_syncObject.Lock();
  }
 
  void unlock()
  {
    m_syncObject.Unlock();
  }
};

SynchronizedObject还定义了一个protected属性的inner class——ExclusiveZone，作为内部使用的辅助类。它用于在当前作用域内锁定一个SynchronizationObject的实例。其 实现类似于std::auto_ptr，它持有一个指向SynchronizationObject对象的指针，ctor中调用lock，dtor中调用 unlock：

class ExclusiveZone
{
  SynchronizationObject *m_syncObject;
 
public:
  ExclusiveZone( SynchronizationObject *syncObject )
      : m_syncObject( syncObject )
  {
    m_syncObject->lock();
  }
 
  ~ExclusiveZone()
  {
    m_syncObject->unlock ();
  }
};

除去这些，SynchronizedObject就很简单了。它持有一个指向SynchronizationObject实例的指针：

SynchronizationObject *m_syncObject;

并管理其生命周期，在dtor中delete之。至于如何传入该指针，则提供了两种方法：

SynchronizedObject::SynchronizedObject( SynchronizationObject *syncObject )
    : m_syncObject( syncObject == 0 ? new SynchronizationObject() : 
                                                                  syncObject )
{
}
 
void SynchronizedObject::setSynchronizationObject( SynchronizationObject *syncObject )
{
  delete m_syncObject; 
  m_syncObject = syncObject;
}

在讲述TestResult之前，还有一些障碍要扫清。

相关文件：TestListener.h

CppUnit的测试结果记录使用了Observer Pattern，在GoF中对该pattern有如下描述：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通 知并被自动更新。在测试执行的过程中，当发生错误时，TestResult就会被告知，而后它会将该信息传递给TestListener。因此， TestResult对应了Observer Pattern中的Subject，而TestListener则对应了Observer。

不过TestListener只是一个什么事都没做的基类，像输出测试结果这样事情还得留待派生类来解决，比如outputter部分要提到的 TextTestProgressListener。此外，还是尽量不要使用Listener进行测试结果的输出为好，应该使用outputter中所提 供的专有工具。

从TestListener的定义可以看到，在如下三类事件发生时，TestListener将会被通知到

• 测试执行之前
• 测试失败
• 测试执行之后

来看一下代码：

// 在一个测试运行前被调用
virtual void startTest( Test *test ) {}
 
// 运行测试失败时被调用
virtual void addFailure( const TestFailure &failure )
 
// 在一个测试运行后被调用
virtual void endTest( Test *test )

addFailure中的failure是临时对象，在该方法调用之后即被销毁，和Exception一样（参见TestCase的run函数），也需要 使用其自身提供的clone方法来创建一个副本。有关TestFailure，稍后将会提到。

至于endTest，即便测试失败，该函数也会被调用，参见TestCase的run函数。

相关文件：TestResult.h，TestResult.cpp

真是千呼万唤始出来啊。TestResult用以收集测试过程中的相关信息，它派生自SynchronizedObject，从而支持多线程。有了前面的 铺垫，对TestResult的理解就变得非常容易了。

TestResult维护了一个指向TestListener对象的指针队列：

protected:
  typedef std::deque<TestListener *> TestListeners;
  TestListeners m_listeners;
 
为获取到测试相关信息，TestListener需要注册到TestResult中，于是就有了addListener方法：
 
void TestResult::addListener( TestListener *listener )
{
  ExclusiveZone zone( m_syncObject );     // ExclusiveZone终于有用武之地了
  m_listeners.push_back( listener );
}

当然还少不了removeListener：

void TestResult::removeListener ( TestListener *listener )
{
  ExclusiveZone zone( m_syncObject );
  m_listeners.erase( std::remove( m_listeners.begin(), 
                        m_listeners.end(), 
                        listener ),
                     m_listeners.end());
}

我们再来看看TestResult作为Subject的那些Notify方法：

void TestResult::addError( Test *test, Exception *e )
{
  addFailure( TestFailure( test, e, true ) );
}
 
void TestResult::addFailure( Test *test, Exception *e )
{
  addFailure( TestFailure( test, e, false ) );
}
 
void TestResult::addFailure( const TestFailure &failure )
{
  ExclusiveZone zone( m_syncObject );
  // 遍历deque<TestListener *>
  for ( TestListeners::iterator it = m_listeners.begin();
      it != m_listeners.end();
      ++it )
    (*it)->addFailure( failure );   // 调用TestListener的addFailure
}
 
void TestResult::startTest( Test *test )
{
  ExclusiveZone zone( m_syncObject );
  // 遍历deque<TestListener *>
  for ( TestListeners::iterator it = m_listeners.begin();
      it != m_listeners.end(); 
      ++it )
    (*it)->startTest( test );   // 调用TestListener的startTest
}
 
void TestResult::endTest( Test *test )
{
  ExclusiveZone zone( m_syncObject );
  // 遍历deque<TestListener *>
  for ( TestListeners::iterator it = m_listeners.begin();
      it != m_listeners.end();
      ++it )
    (*it)->endTest( test );   // 调用TestListener的endTest
}

此处的注释足以说明问题，至于error和failure的区别，在讲到TestFailure时自然会明了。

最后再来看看有关shouldStop的代码，该函数曾在TestSuite的run中出现过：

TestResult::TestResult( SynchronizationObject *syncObject )
    : SynchronizedObject( syncObject )
{
  reset();
}
 
void TestResult::reset()
{
  ExclusiveZone zone( m_syncObject );
  m_stop = false;
}
 
bool TestResult::shouldStop() const
{
  ExclusiveZone zone( m_syncObject );
  return m_stop;
}
 
void TestResult::stop()
{
  ExclusiveZone zone( m_syncObject );
  m_stop = true;
}

没有什么特别的，只是一个m_stop在掌控着一切，而m_stop则是TestResult的一个protected属性的成员变量：

bool m_stop;

相关文件：TestFailure.h，TestFailure.cpp

CppUnit中有两种类型的错误，它们分别是：failure和error。一个failure是可预期的，并可以为断言（assert）所侦测到；而 error则是不可预期的，由异常标示，它并非框架代码所产生。

CppUnit使用TestFailure这一个类同时表示failure和error，请看TestFailure的成员变量定义：

protected:
  // 指向失败的测试对象
  Test *m_failedTest;
  // 指向异常对象（如果有）
  Exception *m_thrownException;
  // 区分failure和error的标记
  bool m_isError;

再来看相关代码：

// 依据failedTest和thrownException，构建一个TestFailure
TestFailure::TestFailure( Test *failedTest, 
        Exception *thrownException,
        bool isError ) :
    m_failedTest( failedTest ), 
    m_thrownException( thrownException ),
    m_isError( isError )
{
}
 
// 返回m_isError，判断是否error的函数
bool TestFailure::isError() const
{
  return m_isError;
}

另外，再来看看有关clone的代码，十分简单：

TestFailure *TestFailure::clone() const
{
  // 创建一个和自身一模一样的实例后返回其指针
  return new TestFailure( m_failedTest, m_thrownException->clone(), m_isError );
}

除了m_isError之外，TestFailure也为另两个成员变量提供了外界访问的接口：

std::string TestFailure::failedTestName() const
{
  return m_failedTest->getName();
}
 
Exception *TestFailure::thrownException() const
{
  return m_thrownException;
}

最后，对于执行失败的测试，TestFailure还记录了其错误所在位置，包括源文件路径和文件内的行号，通过如下接口可以访问到：

SourceLine TestFailure::sourceLine() const
{
  return m_thrownException->sourceLine();
}

可以看到，TestFailure调用了Exception的sourceLine方法。为使外部方便的引用 SourceLine，选择增加自身接口（sourceLine方法），而接口实现仅仅是简单的delegate，这种设计权衡在很多地方都是经常用到 的。关于SourceLine的具体实现，随后就会讲到。

相关文件：SourceLine.h，SourceLine.cpp

记录了有关某个失败测试的错误所在位置，包括源文件路径和文件内的行号。有了它，我们就可以准确定位导致测试失败的原因了。在和Asserter相关的一 些宏中将会用到该类，Exception中也引用了该类。

SourceLine中有两个成员变量，分别对应源文件路径和文件内的行号：

private:
  std::string m_fileName;
  int m_lineNumber;

除了为这两个成员变量提供外界访问的接口外，SourceLine还重载了operator==和operator!=：

int SourceLine::lineNumber() const
{
  return m_lineNumber;
}
 
std::string SourceLine::fileName() const
{
  return m_fileName;
}
 
bool SourceLine::operator ==( const SourceLine &other ) const
{
  return m_fileName == other.m_fileName  &&
          m_lineNumber == other.m_lineNumber;
}
 
bool SourceLine::operator !=( const SourceLine &other ) const
{
  // 调用operator==，即保证了语义的正确，又避免了代码重复
  // 此类做法是库设计中经常用到的，在STL源码中随处可见
  return !( *this == other );
}

可以看出，SourceLine只是简单的包装了错误位置这一信息，至于该信息的设定还需外界决定，那么如何才能记录下源文件中错误所在的位置 呢，SourceLine中还有一个宏，全部的秘密都在这里：

#define CPPUNIT_SOURCELINE() ::CppUnit::SourceLine( __FILE__, __LINE__ )

在需要处调用该宏，比如某个断言，一个SourceLine对象即被构造，m_fileName和m_lineNumber便被初始化为宏展开处的位置信 息。在讲到TestAssert时，你将会看到，这些工作都无需你操心了，因为framework已经安排好一切了。

相关文件：Exception.h，Exception.cpp

这就是前面多次提到过的异常。它派生自std::exception，调用其what方法可以得到有关本次异常的描述信息，在某个断言失败时会抛出异常。

Exception中有一个标识异常类型的inner class——Type，它具有public属性，内部仅有一个常量成员变量m_Type，代表具体类型。唯一的ctor在初始化成员列表中为 m_type赋值，此外还有一个operator==函数：

class Type
{
public:
  Type( std::string type ) : m_type ( type ) {}
 
  bool operator ==( const Type &other ) const
  {
    return m_type == other.m_type;
  }
 
private:
  const std::string m_type;
};

将类型信息用类来封装，应该是典型的OO风格了，这在refactoring一书中被称为“Replace Type Code with Class”技法，另外，读者还可以在该书中找到其它几项相关内容：Replace Conditional with Polymorphism，Replace Type Code with Subclasses，Replace Type Code with State/Strategy，Replace Data Value with Object。

与Type相关的两个函数是type和isInstanceOf：

// 返回Exception的类型
Exception::Type Exception::type()
{
  return Type( "CppUnit::Exception" );
}
 
// 判断exceptionType是否是“CppUnit::Exception”
bool Exception::isInstanceOf( const Type &exceptionType ) const
{
  return exceptionType == type();
}

isInstanceOf实现了一个简单的运行期类型检查，类似于MFC中的IsKindOf。在Exception的派生类中还将见到它。

Exception有两个私有成员变量：

private:
  std::string m_message;     // 与本次异常相关的描述信息
  SourceLine m_sourceLine;   // 异常发生的具体位置

查看Exception的ctor发现有两个不同版本：

Exception( std::string  message = "", 
        SourceLine sourceLine = SourceLine() );
 
#ifdef CPPUNIT_ENABLE_SOURCELINE_DEPRECATED
Exception( std::string  message, long lineNumber, std::string fileName );
#endif

关于这个CPPUNIT_ENABLE_SOURCELINE_DEPRECATED的来历，在随CppUnit所附的ChangeLog中有过“记 载”。早先版本的CppUnit中，Exception并未引用SourceLine类（也就是说没有第一个ctor，当时SourceLine还没“出 世”呢），而是代之以fileName和lineNumber这两个成员变量，这一点从第二个ctor的声明中也能看出来。在随后的一次 refactoring过程中，这两个可怜的家伙被“Introduce Parameter Object”消灭掉了，于是SourceLine取而代之。但是，作为一个发布了的framework，需要考虑到兼容问题，因此以前的接口必须保留， 所以第二个ctor仍然存在，只是其内部实现已偷梁换柱了：

Exception::Exception( std::string message, long lineNumber, std::string fileName ) : 
    m_message( message ), 
    m_sourceLine( fileName, lineNumber )  // 仍然转交给SourceLine
{}

既然是“DEPRECATED”，那么这样的接口当然是不推荐使用的，在Exception源码中还有多处与此有关，这里就不多说了。总之，缺省情况下 CPPUNIT_ENABLE_SOURCELINE_DEPRECATED没有被定义，因此被#ifdef CPPUNIT_ENABLE_SOURCELINE_DEPRECATED……#endif所包围的代码大可不必关心。不过，像这类“历史遗留”问题， 想必很多库设计中都会遇到。

还有几个函数，代码如下：

const char* Exception::what() const throw()
{
  return m_message.c_str ();
}
 
Exception *Exception::clone() const
{
  return new Exception( *this );
}
 
Exception::operator =( const Exception& other )
{
  if ( &other != this )
  {
    m_message = other.m_message;
    m_sourceLine = other.m_sourceLine;
  }
  return *this;
}

相关文件：NotEqualException.h，NotEqualException.cpp

派生自Exception，当判断相等的断言失败时会抛出该异常。和基类相比，多了三个private成员变量：

private:
  std::string m_expected;    // 预期值
  std::string m_actual;          // 实际值，是否仅支持字符串比较呢，稍后再做讲解
  std::string m_additionalMessage;     // 附加信息

NotEqualException还覆盖了基类的type、isInstanceOf、clone、operator=这几个函数：

// 返回NotEqualException类型
Exception::Type NotEqualException::type()
{
  return Type( "CppUnit::NotEqualException" );
}
 
// 调用了基类的isInstanceOf，因此若传入的值为Exception的Type，
// 返回亦为true，这一点与常理相符
bool NotEqualException::isInstanceOf( const Type &exceptionType ) const
{
  return exceptionType == type()  ||
          Exception::isInstanceOf( exceptionType );
}
 
Exception *NotEqualException::clone() const
{
  return new NotEqualException( *this );
}
 
NotEqualException &
NotEqualException::operator =( const NotEqualException &other )
{
  Exception::operator =( other );     // 切勿忘记调用基类的operator=
 
  if ( &other != this )
  {
    m_expected = other.m_expected;
    m_actual = other.m_actual;
    m_additionalMessage = other.m_additionalMessage;
  }
  return *this;
}

从这里开始，将要讲述core中，与断言相关的部分。

相关文件：Asserter.h，Asserter.cpp

Asserter并非类名，而是一个name space，它内嵌于CppUnit name space之中。该域中一共有四个函数，用来帮助编写和断言有关的宏，它们分别 是：fail，failIf，failNotEqual，failNotEqualIf。

函数fail仅抛出一个Exception对象，里面包含了和产生的错误相关的信息：

void fail( std::string message, SourceLine sourceLine )
{
  throw Exception( message, sourceLine );
}

函数failIf加上了条件控制，仅当shouldFail为true时才抛异常（调用fail函数）：

void failIf( bool shouldFail, std::string message, SourceLine location )
{
  if ( shouldFail )
    fail( message, location );
}

类似的，函数failNotEqual抛出NotEqualException对象，表明expected字串和actual字串不相 等，NotEqualException对象包含了和产生的错误相关的信息：

void failNotEqual( std::string expected, std::string actual, 
        SourceLine sourceLine, std::string additionalMessage )
{
  throw NotEqualException( expected, actual, sourceLine, additionalMessage );
}

而函数failNotEqualIf则加上了条件控制：

void failNotEqualIf( bool shouldFail, std::string expected, std::string actual, 
        SourceLine sourceLine, std::string additionalMessage )
{
  if ( shouldFail )
    failNotEqual( expected, actual, sourceLine, additionalMessage );
}

下面的例子演示了如何使用上面提供的函数编写与断言相关的宏，这个例子选自随CppUnit源码所附的范例中：

#include <cppunit/SourceLine.h>
#include <cppunit/TestAssert.h>
 
// 检查XML字串是否与预期值相等
void  checkXmlEqual( std::string expectedXml, 
        std::string actualXml, 
        CppUnit::SourceLine sourceLine )
{
  // 预期之XML字串
  std::string expected = XmlUniformiser( expectedXml ).stripped();
  // 实际之XML字串
  std::string actual = XmlUniformiser( actualXml ).stripped();
 
  if ( expected == actual )    // 实际值和预期值相符，则相安无事
    return;
 
  // 不符，则报之以异常
  ::CppUnit::Asserter::failNotEqual( expected, actual, sourceLine );
}
 
/// 断言：两个XML字串相等
#define CPPUNITTEST_ASSERT_XML_EQUAL( expected, actual ) \
        checkXmlEqual( expected, actual, CPPUNIT_SOURCELINE() )

相关文件：TestAssert.h，TestAssert.cpp

TestAssert并非类名，而是一个name space，它内嵌于CppUnit name space之中。该域中也有CPPUNIT_ENABLE_SOURCELINE_DEPRECATED的痕迹，去除与之相关的代码，剩下两个函数： assertEquals和assertDoubleEquals，其余均是宏。

assertEauals为模板函数，其大致功能类似前面的checkXmlEqual函数，若实际值和预期值不相符，则调用 Asserter::failNotEqual，来看一下代码：

template <class T>
void assertEquals( const T& expected, const T& actual, 
        SourceLine sourceLine, const std::string &message ="" )
{
  if ( !assertion_traits<T>::equal(expected,actual) )
  {
    // 在需要时才调用toString，此之谓“lazy toString conversion”
    Asserter::failNotEqual( assertion_traits<T>::toString(expected), 
            assertion_traits<T>::toString(actual), 
            sourceLine, 
            message );
  }
}

之所以采用模板是为了使之支持多种类型，但是assertion_traits<T>::equal又是何方神圣呢。看到这个traits， 想必大家一定会想到在泛型编程中大名鼎鼎的特性萃取技法。不错，这就是traits技法在此处的一个小小的应用。 assertion_traits的定义和TestAssert同在一个文件中：

template <class T>
struct assertion_traits
{
  static bool equal( const T& x, const T& y )
  {
    return x == y;
  }
 
  static std::string toString( const T& x )
  {
    OStringStream ost;
    ost << x;
    return ost.str();
  }
};

assertion_traits的功能就是从T中萃取与断言相关的两个特征：equal和toString，上面提供的是泛化版本，根据需要你还可以定 义特化版本，比如专门为std::string定制的代码如下：

template<>
struct assertion_traits<std::string>
{
  static bool equal( const std::string& x, const std::string& y )
  {
    return x == y;
  }
 
  static std::string toString( const std::string& x )
  {
    std::string text = '"' + x + '"';    // 两边加上引号以留空
    OStringStream ost;
    ost << text;
    return ost.str();
  }
};

assertEquals中利用assertion_traits<T>::equal判断 expected与actual是否相等，若不等则调用Asserter::failNotEqual函数。到此，对于 NotEqualException中仅对字串作比较的疑问，相信读者已经明白缘由了。有了assertion_traits<T>:: toString，不管什么类型，一个string版的NotEqualException足以应对。

理解了assertEquals之后，再来看assertDoubleEquals函数就十分简单了，该函数用于作模糊相等判断，针对的是double类 型的数据：

void TestAssert::assertDoubleEquals( double expected,
        double actual,
        double delta,
        SourceLine sourceLine )
{
  Asserter::failNotEqualIf( fabs( expected - actual ) > delta,
    assertion_traits<double>::toString(expected),
    assertion_traits<double>::toString(actual),
    sourceLine );
}

当expected和actual的差值的绝对值大于限值delta，则调用Asserter::failNotEqualIf，此处再次使用了 assertion_traits<T>::toString，T以double代之。

好了，现在万事俱备，有了这些工具，就可以编写与断言相关的宏了，正如前面的checkXmlEqual函数。用这些宏，我们可以得到错误发生的文件物理 位置和行号：

#if CPPUNIT_HAVE_CPP_SOURCE_ANNOTATION
// 断言条件condition为真
#define CPPUNIT_ASSERT(condition)                          \
  ( ::CppUnit::Asserter::failIf( !(condition),             \
        (#condition),             \
        CPPUNIT_SOURCELINE() ) )
#else
#define CPPUNIT_ASSERT(condition)                          \
  ( ::CppUnit::Asserter::failIf( !(condition),             \
        "",                       \
        CPPUNIT_SOURCELINE() ) )
#endif
 
// 断言条件condition为真，若为假，message中指明了诊断信息
#define CPPUNIT_ASSERT_MESSAGE(message,condition)          \
  ( ::CppUnit::Asserter::failIf( !(condition),             \
        (message),                \
        CPPUNIT_SOURCELINE() ) )
 
// 表示失败，message中指明了诊断信息
#define CPPUNIT_FAIL( message )                            \
  ( ::CppUnit::Asserter::fail( message,                    \
        CPPUNIT_SOURCELINE() ) )
 
// 断言两个值相等，若不相等，则会打印诊断信息
#define CPPUNIT_ASSERT_EQUAL(expected,actual)                     \
  ( ::CppUnit::TestAssert::assertEquals( (expected),              \
        (actual),                \
        CPPUNIT_SOURCELINE() ) )
 
// 断言两个值相等，message中指明了附加的诊断信息
#define CPPUNIT_ASSERT_EQUAL_MESSAGE(message,expected,actual)     \
  ( ::CppUnit::TestAssert::assertEquals( (expected),              \
        (actual),                \
        CPPUNIT_SOURCELINE(),    \
        (message) ) )
 
// 断言两个值不精确相等
#define CPPUNIT_ASSERT_DOUBLES_EQUAL(expected,actual,delta)       \
  ( ::CppUnit::TestAssert::assertDoubleEquals( (expected),        \
        (actual),          \
        (delta),           \
        CPPUNIT_SOURCELINE() ) )

关于CPPUNIT_ASSERT_EQUAL还有一点要说明，该宏对于expected和actual是有要求的，也就是所谓的 Requirement：

• 具有相同的类型（比如都是std::string）
• 可以使用?序列化到std::strstream（assertion_traits<T>::toString中指明）
• 能用==作比较（assertion_traits<T>::equal中指明）

不过，后两条可以通过为assertion_traits定制特化版本去除掉。

最后，TestAssert还定义了与上述宏功能相当的另一组宏，依据ChangeLog的描述，这又是“历史遗留”问题：为了与早先版本兼容，即早先使 用的是如下这组宏。若你仍需使用这些宏，只要在所有CppUnit包含文件之前将宏 CPPUNIT_ENABLE_NAKED_ASSERT定义为1即可：

#if CPPUNIT_ENABLE_NAKED_ASSERT
 
#undef assert
#define assert(c)                 CPPUNIT_ASSERT(c)
#define assertEqual(e,a)          CPPUNIT_ASSERT_EQUAL(e,a)
#define assertDoublesEqual(e,a,d) CPPUNIT_ASSERT_DOUBLES_EQUAL(e,a,d)
#define assertLongsEqual(e,a)     CPPUNIT_ASSERT_EQUAL(e,a)
 
#endif

这一部分主要提供了一些用于输出测试结果的工具类，输出的方式可以有多种，比如：以纯文本方式输出，以XML标记语言方式输出，基于IDE开发环境的输出 等。由此足见，CppUnit的实现者想得还是很周到的。

相关文件：Outputter.h

这是一系列测试结果输出类的抽象基类，只有寥寥几行代码，唯一的作用是定义了一个write操作和一个virtual dtor：

virtual ~Outputter() {}
virtual void write() =0;

由于各种输出方式，其具体实现大相径庭，所以Outputter所能做的也止于此了。

相关文件：TestResultCollector.h，TestResultCollector.cpp

该类派生自TestSucessListener，同样也是TestListener和 SynchronizedObject，因为前者派生自后二者。关于TestSucessListener请见listener部分，关于 TestListener请见core部分。TestResultCollector的作用是搜集正在执行的测试用例的结果。依源码中的 documentation comments所述，这是Collecting Parameter Pattern的一个应用[该Pattern在GoF中没有提及，morning有些孤陋寡闻]

TestSucessListene定义了三个成员变量，用来记录测试相关信息：

std::deque<Test *> m_tests;            // 指针队列用以记录测试对象
std::deque<TestFailure *> m_failures;  // 指针队列用以记录测试失败信息
int m_testErrors;                      // 用以记录测试错误个数

TestSucessListene还覆盖了基类TestListener的startTest，reset和addFailure方法：

void TestResultCollector::startTest( Test *test )
{
  ExclusiveZone zone (m_syncObject); 
  m_tests.push_back( test );               // 将测试对象加入链表中
}
 
void TestResultCollector::reset()
{
  TestSucessListener::reset();
 
  ExclusiveZone zone( m_syncObject ); 
  m_testErrors = 0;
  m_tests.clear();
  m_failures.clear();
}
 
void TestResultCollector::addFailure( const TestFailure &failure )
{
  TestSucessListener::addFailure( failure );
 
  ExclusiveZone zone( m_syncObject ); 
  if ( failure.isError() )                   // 若failure实为error，则m_testErrors加1
    ++m_testErrors;
  m_failures.push_back( failure.clone() );   // 此处用了clone
}

这里使用了ExclusiveZone，关于failure和error的差别，以及clone方法，请见core部分。由于使用了clone方法，所以 在addFailure中创建的failure需要在dtor中回收：

TestResultCollector::~TestResultCollector()
{
  TestFailures::iterator itFailure = m_failures.begin();
  while ( itFailure != m_failures.end() )
    delete *itFailure++;
}

此外，就是几个getter方法了：

// 获取运行的测试个数
int TestResultCollector::runTests() const
{ 
  ExclusiveZone zone( m_syncObject ); 
  return m_tests.size(); 
}
 
// 获取运行错误的测试个数
int TestResultCollector::testErrors() const
{ 
  ExclusiveZone zone( m_syncObject );
  return m_testErrors;
}
 
// 获取运行失败的测试个数
int TestResultCollector::testFailures() const
{ 
  ExclusiveZone zone( m_syncObject ); 
  return m_failures.size() - m_testErrors;
}
 
// 获取运行错误及失败的测试的总个数
int TestResultCollector::testFailuresTotal() const
{
  ExclusiveZone zone( m_syncObject ); 
  return m_failures.size();
}
 
// 获取记录测试失败的链表
const TestResultCollector::TestFailures & 
TestResultCollector::failures() const
{ 
  ExclusiveZone zone( m_syncObject );
  return m_failures; 
}
 
// 获取记录测试对象的链表
const TestResultCollector::Tests &
TestResultCollector::tests() const
{
  ExclusiveZone zone( m_syncObject );
  return m_tests;
}

这里还想提一下有关TestResult和TestResultCollector的区别。根据随CppUnit所附的ChangeLog中的“记载”， 早先版本的CppUnit中只有TestResult，它所实现的功能和TestResultCollector完全一样，像failures、 testFailuresTotal等方法，原来都是在TestResult中的。不过在随后的refactoring过程中，由于引入了 Observer Pattern，TestResultCollector应运而生，TestResult成了Subject，其原有记录测试运行结果的责任被移交给了 TestResultCollector，而后者则是一个地道的Listener。于是原来在TestResult中出现的那些方法在Extract Method的“协助”之下被转移到了TestResultCollector中。

相关文件：TextOutputter.h，TextOutputter.cpp

Outputter的派生类，以纯文本格式输出TestResultCollector中的内容。通过ctor将所要输出的 TestResultCollector对象以及输出设备对象传入其中：

TextOutputter::TextOutputter( TestResultCollector *result,
                              std::ostream &stream )
    : m_result( result )
    , m_stream( stream )
{
}

还覆盖了基类Outputter的write方法：

void TextOutputter::write() 
{
  printHeader();
  m_stream << std::endl;
  printFailures();
  m_stream << std::endl;
}

至于pringHeader，printFailures以及其他辅助函数的具体实现，此处不再叙述，这些内容多半是复杂的格式化输出，感兴趣的读者可以 查看源码。

相关文件：CompilerOutputter.h，CompilerOutputter.cpp

Outputter的又一个派生类，功能类似于TextOutputter，以编译器兼容方式（compiler compatible）输出TestResultCollector中的内容，以使你在IDE环境下可以跳转至相应的assertion failure。这就好像在IDE环境下编译程序产生了错误，而你可以在错误结果输出窗口中点击错误所在行跳转至对应的源码处。 CompilerOutputter会在编译期间的末尾运行测试，在IDE的监视窗口中提供反馈结果，并且同样具有跳转至对应源码处的功能。

来看看CompilerOutputter到底有何神奇之处，能有如此非凡功能。

与TextOutputter类似，通过ctor将所要输出的TestResultCollector对象以及输出设备对象传入其中：

CompilerOutputter::CompilerOutputter( TestResultCollector *result,
                                      std::ostream &stream ) :
    m_result( result ),
    m_stream( stream )
{
}

同样也覆盖了基类Outputter的write方法：

void CompilerOutputter::write()
{
  if ( m_result->wasSuccessful() )
    printSucess();
  else
    printFailureReport();
}

然后是一些以print打头的格式化输出函数，此处不再鏊述。略有不同的是，多了一个splitMessageIntoLines函数和一个wrap函 数。splitMessageIntoLines用于将一个字符串按行（即以“\n”为界）拆成一个字符串数组：

CompilerOutputter::Lines 
CompilerOutputter::splitMessageIntoLines( std::string message )
{
  Lines lines;
 
  std::string::iterator itStart = message.begin();
  while ( true )
  {
    std::string::iterator itEol = std::find( itStart, 
                                             message.end(), 
                                             '\n' );
    lines.push_back( message.substr( itStart - message.begin(),
                                     itEol - itStart ) );
    if ( itEol == message.end() )
      break;
    itStart = itEol +1;
  }
  return lines;
}

至于wrap，则是在调用splitMessageIntoLines后，对每行以80列为限，若超过就作折行处理。这些处理都是为了方便在IDE监视窗 口中查看输出结果。即，不用因为单行内容太多，而来回移动横向滚动条：

std::string
CompilerOutputter::wrap( std::string message )
{
  Lines lines = splitMessageIntoLines( message );
  std::string wrapped;
  for ( Lines::iterator it = lines.begin(); it != lines.end(); ++it )
  {
    std::string line( *it );
    const int maxLineLength = 80;
    int index =0;
    while ( index < line.length() )
    {
      std::string line( line.substr( index, maxLineLength ) );
      wrapped += line;
      index += maxLineLength;
      if ( index < line.length() )
        wrapped += "\n";
    }
    wrapped += '\n';
  }
  return wrapped;
}

到此为止，还是没有看到CompilerOutputter有何特殊之处，我们来看一下，实际调用CompilerOutputter的例子，以下这段代 码是从随CppUnit源码所附的范例中抽取出来的：

int main( int argc, char* argv[] ) {
  // if command line contains "-selftest" then this is the post build check
  // => the output must be in the compiler error format.
  bool selfTest = (argc > 1)  &&  
                  (std::string("-selftest") == argv[1]);
 
  CppUnit::TextUi::TestRunner runner;
  runner.addTest( CppUnitTest::suite() );   // Add the top suite to the test runner
 
  if ( selfTest )
  { // Change the default outputter to a compiler error format outputter
    // The test runner owns the new outputter.
    runner.setOutputter( CppUnit::CompilerOutputter::defaultOutputter( 
                                                       &runner.result(),
                                                        std::cerr ) );
  }
 
  // Run the test and don't wait a key if post build check.
  bool wasSucessful = runner.run( "", !selfTest );
 
  // Return error code 1 if the one of test failed.
  return wasSucessful ? 0 : 1;
}

从注释中可以看到，针对本例，关键环节，只是在Project Settings的Post-build step处加上一个自定义命令，当然这是针对VC IDE而言的：

$(TargetPath) -selftest

$(TargetPath)代表编译后生成的exe文件，-selftest则是命令行参数。有了这项设置，IDE的compiler就会在编译结束之 后，即刻运行本测试程序。以下是一个运行结果的实例：

1  --------------------Configuration: CppUnitTestMain - Win32 Debug--------------------
2  Compiling...
3  ExceptionTest.cpp
4  Linking...
5  self test
6  .F...................................................................................
7  c:\program\cppunit-1.8.0\examples\cppunittest\exceptiontest.cpp(43) : Assertion
8  Test name: ExceptionTest.testConstructor
9  sourceLine != e.sourceLine()
10 Failures !!!
11 Run: 112   Failure total: 1   Failures: 1   Errors: 0
12 Error executing c:\winnt\system32\cmd.exe.
13
14 CppUnitTestMain.exe - 1 error(s), 0 warning(s)

其中，第1~4行以及第12~14是程序编译链接的正常输出，第5行是Post-build step中所指定的command的描述性文字，第6行是TextTestProgressListener的输出内容，第7~11行就是 CompilerOutputter的输出内容。此处表明，在exceptiontest.cpp的第43行，有一个断言失败了，鼠标双击该行，即可转到 相应的源文件处。

相关文件：XmlOutputter.h，XmlOutputter.cpp

Outputter的又一个派生类，其功能是以XML格式输出TestResultCollector中的内容。与前述的TextOutputter和 CompilerOutputter类似，XmlOutputter也覆盖了基类Outputter的write方法：

void XmlOutputter::write()
{
  writeProlog();
  writeTestsResult();
}

不同的是，XmlOutputter多了一个成员变量m_encoding，它用来标记XML的编码方式，缺省值是ISO-8859-1。由此，ctor 也略有不同了：

XmlOutputter::XmlOutputter( TestResultCollector *result,
                            std::ostream &stream,
                            std::string encoding ) :
    m_result( result ),
    m_stream( stream ),
    m_encoding( encoding )
{
}

writeProlog函数的作用是填写XML的头信息，很简单，不再多说。至于writeTestsResult，则是用来输出整个XML数据流的：

void XmlOutputter::writeTestsResult()
{
  Node *rootNode = makeRootNode();
  m_stream  <<  rootNode->toString();
  delete rootNode;
}

writeTestsResult首先调用makeRootNode方法生成XML数据流的根节点，然后调用节点的 toString方法输出实际数据流，最后回收资源。这里出现了Node类，关于Node类的细节，稍后会讲到。先来看看与 writeTestsResult相关的几个函数

XmlOutputter::Node *XmlOutputter::makeRootNode()
{
  Node *rootNode = new Node( "TestRun" );
 
  FailedTests failedTests;
  fillFailedTestsMap( failedTests );
 
  addFailedTests( failedTests, rootNode );
  addSucessfulTests( failedTests, rootNode );
  addStatistics( rootNode );
 
  return rootNode;
}
 
void XmlOutputter::fillFailedTestsMap( FailedTests &failedTests )
{
  const TestResultCollector::TestFailures &failures = m_result->failures();
  TestResultCollector::TestFailures::const_iterator itFailure = failures.begin();
  while ( itFailure != failures.end() )
  {
    TestFailure *failure = *itFailure++;
    failedTests.insert( std::make_pair(failure->failedTest(), failure ) );
  }
}
 
void XmlOutputter::addFailedTests( FailedTests &failedTests,
                                   Node *rootNode )
{
  Node *testsNode = new Node( "FailedTests" );
  rootNode->addNode( testsNode );
 
  const TestResultCollector::Tests &tests = m_result->tests();
  for ( int testNumber = 0; testNumber < tests.size(); ++testNumber )
  {
    Test *test = tests[testNumber];
    if ( failedTests.find( test ) != failedTests.end() )
      addFailedTest( test, failedTests[test], testNumber+1, testsNode );
  }
}
 
void XmlOutputter::addSucessfulTests( FailedTests &failedTests,
                                      Node *rootNode )
{
  Node *testsNode = new Node( "SucessfulTests" );
  rootNode->addNode( testsNode );
 
  const TestResultCollector::Tests &tests = m_result->tests();
  for ( int testNumber = 0; testNumber < tests.size(); ++testNumber )
  {
    Test *test = tests[testNumber];
    if ( failedTests.find( test ) == failedTests.end() )
      addSucessfulTest( test, testNumber+1, testsNode );
  }
}
 
void XmlOutputter::addStatistics( Node *rootNode )
{
  Node *statisticsNode = new Node( "Statistics" );
  rootNode->addNode( statisticsNode );
  statisticsNode->addNode( new Node( "Tests", m_result->runTests() ) );
  statisticsNode->addNode( new Node( "FailuresTotal", 
                                     m_result->testFailuresTotal() ) );
  statisticsNode->addNode( new Node( "Errors", m_result->testErrors() ) );
  statisticsNode->addNode( new Node( "Failures", m_result->testFailures() ) );
}
 
void XmlOutputter::addFailedTest( Test *test,
                                  TestFailure *failure,
                                  int testNumber,
                                  Node *testsNode )
{
  Exception *thrownException = failure->thrownException();
 
  Node *testNode = new Node( "FailedTest", thrownException->what() );
  testsNode->addNode( testNode );
  testNode->addAttribute( "id", testNumber );
  testNode->addNode( new Node( "Name", test->getName() ) );
  testNode->addNode( new Node( "FailureType", 
                               failure->isError() ? "Error" : "Assertion" ) );
 
  if ( failure->sourceLine().isValid() )
    addFailureLocation( failure, testNode );
}
 
void XmlOutputter::addFailureLocation( TestFailure *failure,
                                       Node *testNode )
{
  Node *locationNode = new Node( "Location" );
  testNode->addNode( locationNode );
  SourceLine sourceLine = failure->sourceLine();
  locationNode->addNode( new Node( "File", sourceLine.fileName() ) );
  locationNode->addNode( new Node( "Line", sourceLine.lineNumber() ) );
}
 
void XmlOutputter::addSucessfulTest( Test *test, 
                                     int testNumber,
                                     Node *testsNode )
{
  Node *testNode = new Node( "Test" );
  testsNode->addNode( testNode );
  testNode->addAttribute( "id", testNumber );
  testNode->addNode( new Node( "Name", test->getName() ) );
}

依据上述代码可以大致勾画出XML数据流的生成流程：

makeRootNode函数虽名曰创建根节点，实则创建整个XML数据流。在创建了一个名为 “TestRun”的根节点之后，随即调用了fillFailedTestsMap方法，后者调用成员变量m_result的failures方法，得到 所有失败之测试，填充一个FailedTests结构的变量以备后用(实为map<Test *,TestFailure*>)。

addFailedTests方法，生成了一个名为“FailedTests”的节点，作为 “TestRun”的子节点，并调用了m_result的tests方法，针对每个测试，若能在前面填充的FailedTests结构的变量中找到(即为 失败测试)，则调用addFailedTest方法。后者生成一个名为“FailedTest”的节点，作为“FailedTests”的子节点， “FailedTest”节点的content描述了错误原因，这是通过调用Exception的what方法得到的，而Excetpion的实例则是通 过调用失败测试的thrownException方法获取的。“FailedTest”节点有一个属性，表示测试的ID号，另外其下还有两个子节点，一个 是测试名称，另一个是失败类型(Error/Assertion)。若有可能，还会记录错误所在的文件位置和行号。

与addFailedTests方法类似的另一个函数是addStatistics，它用来生成和成功测试相关的节点。此处不再鏊述。

addStatistics方法在最后被调用，用以生成统计信息，包括：测试个数（名为 “Tests”的节点），失败测试总数（名为“FailuresTotal”的节点），错误个数（名为“Errors”的节点），失败个数（名为 “Failures”的节点）。它们都从属于“Statistics”节点，而该节点则直接从属于根节点。

最后，再捎带提一下Node类，该类内嵌于XmlOutputter中，实现了一个功能简单的 XML节点类，在后续版本中可能为一个Abstract Builder所取代。节点的内容(content）支持int型和string型数据，这一点可以从其两个不同版本的ctor中看到：

XmlOutputter::Node::Node( std::string elementName,
                          std::string content ) :
    m_name( elementName ),
    m_content( content )
{
}
 
XmlOutputter::Node::Node( std::string elementName,
                          int numericContent ) :
    m_name( elementName )
{
  m_content = asString( numericContent );
}

其中的asString是Node的一个辅助方法，用以将int型数据转换成string型数据。m_name和m_content分别代表节点对应的名 称和内容。

Node中的m_attributes成员，代表了节点包含的属性，事实上，它对应的是一个 deque类型的变量，而deque的每个元素则是std::pair<std::string,std::string>类型的，其中前一 个string代表属性名，后一个string代表属性值。有了上述认识，我们就可以理解Node的addAttribute方法的含义了，同样是为了支 持int型数据和string型数据，addAttribute具有两个版本：

void XmlOutputter::Node::addAttribute( std::string attributeName,
                                       std::string value  )
{
  m_attributes.push_back( Attribute( attributeName, value ) );
}
 
void XmlOutputter::Node::addAttribute( std::string attributeName,
                                       int numericValue )
{
  addAttribute( attributeName, asString( numericValue ) );
}

这里的Attribute即std::pair<std::string,std::string>：

typedef std::pair<std::string,std::string> Attribute;

由于XML的标记呈现树状结构的特点，因此作为标记对应物的Node类也应该支持这种节点嵌套的特性。因此，Node 类中引入了m_nodes成员，用以代表当前节点下属的子节点，其实际类型是std::deque<Node *>。与之对应的addNode方法用以为当前节点添加一个新的子节点：

void XmlOutputter::Node::addNode( Node *node )
{
  m_nodes.push_back( node );
}

接下来是至为关键的toString方法，前面提到的XmlOutputter正是调用了根节点的toString方法才完成整个XML数据流的输出的：

std::string XmlOutputter::Node::toString() const
{
  // 添加begin tag
  std::string element = "<";
  element += m_name;
  element += " ";
  element += attributesAsString();
  element += " >\n";
 
  // 递归调用子节点的toString方法
  Nodes::const_iterator itNode = m_nodes.begin();
  while ( itNode != m_nodes.end() )
  {
    const Node *node = *itNode++;
    element += node->toString();
  }
 
  // 添加tag content
  element += m_content;
 
  // 添加end tag
  element += "</";
  element += m_name;
  element += ">\n";
 
  return element;
}

代码中的注释已清楚描述了toString的执行流程，需要再解释一下的是在生成启始标记时出现的attributesAsString方法：

std::string XmlOutputter::Node::attributesAsString() const
{
  std::string attributes;
  Attributes::const_iterator itAttribute = m_attributes.begin();
  while ( itAttribute != m_attributes.end() )
  {
    const Attribute &attribute = *itAttribute++;
    attributes += attribute.first;
    attributes += "=\"";
    attributes += escape( attribute.second );
    attributes += "\"";
  }
  return attributes;
}

可以看出，attributesAsString的作用是把当前节点的属性转换成字符串，并逐个拼接起来。至于escape方法，则是用来替换字符串中的 某些特殊字符的，但其做法似乎简陋了些，怪不得作者要在旁边加上safe?这样的注释。

std::string XmlOutputter::Node::escape( std::string value ) const
{
  std::string escaped;
  for ( int index =0; index < value.length(); ++index )
  {
    char c = value[index ];
    switch ( c )    // escape all predefined XML entity (safe?)
    {
    case '<': 
      escaped += "<";
      break;
    case '>': 
      escaped += ">";
      break;
    case '&': 
      escaped += "&";
      break;
    case '\'': 
      escaped += "'";
      break;
    case '"': 
      escaped += "";
      break;
    default:
      escaped += c;
    }
  }
 
  return escaped;
}

至此，XmlOutputter部分的讲解就完成了。

这一部分提供了一些辅助类，多数与创建Test类的实例有关，其中包括用于创建Test的工厂类，用于管理工厂类的注册类，可以单独运行某个测试的 TestCaller，还有为方便使用而定义的一组宏。

相关文件：TypeInfoHelper.h，TypeInfoHelper.cpp

为了扫清理解障碍，TypeInfoHelper是首先需要解释的。该类的作用是根据指定类的 type_info返回一个代表其类名的字符串。为了使用此功能，你必须定义CPPUNIT_USE_TYPEINFO_NAME宏，即你必须确认你所使 用的c++编译器提供了type_info机制。TypeInfoHelper仅有一个static成员函数getClassName，请留意 morning的注释：

std::string 
TypeInfoHelper::getClassName( const std::type_info &info )
{
  static std::string classPrefix( "class " );
  std::string name( info.name() );      // 调用info的name以得到类名信息
 
  // 确定类名中是否有"class"字样
  bool has_class_prefix = 0 ==
#if CPPUNIT_FUNC_STRING_COMPARE_STRING_FIRST
    name.compare( classPrefix, 0, classPrefix.length() );
#else
    name.compare( 0, classPrefix.length(), classPrefix );
#endif
 
  // 返回不带有"class"字样的类名
  return has_class_prefix ? name.substr( classPrefix.length() ) : name;
}

关于此处用到的std::string::compare函数，在bcb和vc中的调用方式不一样，所以就有了 CPPUNIT_FUNC_STRING_COMPARE_STRING_FIRST宏。参见config-msvc6.h和config-bcb5.h 中的相关定义以及portability部分的说明。

相关文件：TestFactory.h

是Test的抽象类工厂（Abstract Factory），用于创建一个Test实例，它仅仅包含了一个纯虚函数makeTest的声明：

virtual Test* makeTest() = 0;

相关文件：TestFactoryRegistry.cpp，TestFactoryRegistry.cpp

某次测试的运行可能包含了许多测试实例，它们彼此间可能呈现层状结构，而每个测试实例的创建都是由某个与之对应的类工厂完成的。为了较好的管理这些类工 厂，实现其生命周期的自动操控，CppUnit采用了一种注册机制。类 TestFactoryRegistry和类NamedRegistries就是用来实现该机制的。

NamedRegistries是一个管理类，用以管理所有的注册项——TestFactoryRegistry类的实例，由它全权负责 TestFactoryRegistry的生命周期。TestFactoryRegistry在稍后会讲到。

NamedRegistries采用了Singleton Pattern，以保证其“全局性”的唯一访问点。此处是通过在函数内定义静态变量的方式来实现的：

NamedRegistries &
NamedRegistries::getInstance()
{
  static NamedRegistries namedRegistries;
  return namedRegistries;
}

NamedRegistries内部有三个private属性的成员变量：

Registries m_registries;        // 代表一个注册名称-注册项的映射表
Factories m_factoriesToDestroy; // 代表即将被销毁的注册项序列
Factories m_destroyedFactories; // 代表已经被销毁的注册项序列

其中，Registries和Factories的定义如下：

typedef std::map<std::string, TestFactoryRegistry *> Registries;
typedef std::set<TestFactory *> Factories;

为了使外界可以访问到注册项，NamedRegistries提供了getRegistry方法，请留意morning的注释：

TestFactoryRegistry &
NamedRegistries::getRegistry( std::string name )
{
  // 根据name在m_registries中查找注册项
  Registries::const_iterator foundIt = m_registries.find( name );
  // 若没有找到，则创建一个TestFactoryRegistry实例，并赋以name作为名称
  // 将之分别插入m_registries和m_factoriesToDestroy中
  // 再返回该TestFactoryRegistry实例
  if ( foundIt == m_registries.end() )
  {
    TestFactoryRegistry *factory = new TestFactoryRegistry( name );
    m_registries.insert( std::make_pair( name, factory ) );
    m_factoriesToDestroy.insert( factory );
    return *factory;
  }
  // 若找到，则直接返回
  return *foundIt->second;
}

在NamedRegistries被销毁（即dtor被调用）的同时，其下所属的TestFactoryRegistry实例也将被销毁：

NamedRegistries::~NamedRegistries()
{
  Registries::iterator it = m_registries.begin();
  while ( it != m_registries.end() )
  {
    TestFactoryRegistry *registry = (it++)->second;
    if ( needDestroy( registry ) )
      delete registry;
  }
}

这里加上needDestroy的判断是为了防止出现多次销毁同一个TestFactoryRegistry实例的现象，稍后可以发现这和 TestFactoryRegistry的dtor实现有关，另外一个wasDestroyed方法，也与此有关，它们的实现代码分别如下：

void 
NamedRegistries::wasDestroyed( TestFactory *factory )
{
  // 从m_factoriesToDestroy中摘除factory
  m_factoriesToDestroy.erase( factory );
  // 将factory插入m_destroyedFactories
  m_destroyedFactories.insert( factory );
}
 
bool 
NamedRegistries::needDestroy( TestFactory *factory )
{
  // 判断m_destroyedFactories是否存在factory
  return m_destroyedFactories.count( factory ) == 0;
}

根据约定，TestFactory的注册项必须调用wasDestroyed方法，以表明一个 TestFactoryRegistry实例已经被成功销毁了。同时，它也需要调用needDestroy以确信一个给定的TestFactory可以被 允许销毁，即事先没有被其他TestFactoryRegistry实例销毁。

我们再来看看TestFactoryRegistry。其ctor只是简单的将传入其中的字符串赋给成员变量m_name，它代表了注册项的名称：

TestFactoryRegistry::TestFactoryRegistry( std::string name ) :
    m_name( name )
{
}

dtor稍微复杂一些，请留意morning的注释：

TestFactoryRegistry::~TestFactoryRegistry()
{
  // 还记得前面提到的约定吗？
  NamedRegistries::getInstance().wasDestroyed( this );
 
  // 遍历其下所属的各个TestFactory实例
  for ( Factories::iterator it = m_factories.begin(); it != m_factories.end(); ++it )
  {
    TestFactory *factory = it->second;
    // 若factory没有存在于NamedRegistries::m_destroyedFactories中
    // 则可以放心销毁之。factory的销毁可能形成连锁反应，亦即，若factory本身
    // 也是TestFactoryRegistry类型的，其dtor又将被调用，上述过程将再次重现
    if ( NamedRegistries::getInstance().needDestroy( factory ) )
      delete factory;
  }
}