C++测试架构的选择

 衡量指标：

　　1.加入新测试最小化工作量

　　2.便于修改和移植（作者的意思是说比如RTTI，STL，Exception这些高级特性可能妨碍在不同的平台，不同版本编译器下面的可移植性）

　　3.便于装配/拆卸测试环境

　　4.对异常以及崩溃很好的控制

　　5.好的断言功能

　　6.支持不同的输出方式

　　7.支持测试套件(suites)

　　按照这个标准，对下面的test framework进行了评价：

　　CPPUnit

　　1.工作量多

　　2.CPPUnit能在Windows , Linux上面运行，功能进行了很好的模块化，但是另一方面，CPPUnit需要RTTI，STL，或者异常（作者不是很肯定）

　　3.

　　4.CPPUnit使用protectors包装测试，并且捕捉所有的异常（尝试识别某些异常），Linux下面不会捕捉系统异常，但是要增加自定义的包装是很容易的。

　　5.很好，支持一个最小集合的断言语句，包括比较浮点数。

　　6.支持

　　7.支持

　　总体评价：Overall, CppUnit is frustrating because it's almost exactly what I want, except for my most wanted feature. (CPPUnit够闷的，不过我觉得改进易用性应该可以期待）

　　Boost.Test（我尝试使用，在VC.Net 2003下面遇到链接问题，还没有解决）

　　1.基本满足

　　2.和CPPUnit类似，但强调的是改代码的难度以及依赖Boost本身

　　3.避开了常规的setup/teardown结构，可以不需要动态生成fixture 对象，可以将fixture对象放到stack里面。

　　4.Boost.Test在这方面超过了所有的其他竞争对手

　　5.Yes

　　6.大概能支持，但改变输出这件事情并不是很容易

　　7.支持，...（这句如何理解？Yes, but with a big catch）

　　CppUnitLite（由于作者比较了一个被他改动的版本，我不再关注）

　　NanoCppUnit（这个库甚至需要你去从web pages上面copy代码，然后自己搞一个工程，我觉得我不太喜欢这种方式的package发布，毕竟，我希望少操心，所以我也不关注）

　　Unit++

　　首先指出一个独特的特性：More C++ Like，作者的意思是它没有使用宏，的确，前面几种framework开始一个测试的时候都使用了宏，这在许多C++ Library中是惯例，用来简化一些代码。我们通过从基类继承从而创建测试包，当然在其他framework里面本质也是这样，但是都放在幕后进行，宏掩盖了具体情况。

　　1.不好

　　2.一般般

　　3.不支持

　　4.表现平均

　　5.文档没说如何支持不同的输出

　　6.不支持浮点数

　　7.支持

　　CxxTest

　　首先作者认为文档最好（很重要？）另外作者指出,CxxTest的作者Erez Volk意识到我们是在写工具帮助测试C++程序，所以不必受限于C++的特征。

　　1.非常好

　　2.很好

　　3.支持

　　4.很好

　　5.yes

　　6.yes

　　7.yes