使用单元测试 Boost.test

http://www.cnblogs.com/zhihuichien/archive/2010/09/01/1815185.html

　　使用单元测试已有一段时间，在使用过程中，觉得Boost.test的介绍中对单元测试的总结是非常恰当的：

　　（1）需求确定后，先写单元测试代码，测试代码随需求而变。

　　（2）测试代码着眼于被测代码应该如何运行，而不是复现被测代码是如何实现的。

　　（3）能否写好单元测试代码表示对需求的理解是否到位。

　　（4）如果每个模块都经过单元测试，那么集成后出现的问题就可以确认为是模块间传递消息时出现的问题，从而将bug隔离出来，这是单元测试的真正亮点。

　　原文见http://www.boost.org/doc/libs/1_43_0/libs/test/doc/html/tutorials/intro-in-testing.html

　　另外，遇要提及的是，由于团队处于发展过程中，开发流程上有很多不规范之处，接口设计和原型设计不是很细致，这时候，单元测试还有另外的作用：

　　（1）由作者表明如何正确的使用接口，凡是在单元测试中用过的代码，只要注意上下文环境，可以作为开发的参考。

　　（2）向团队中的其他人表明一个人写的代码经过了检验，便于定位软件中的bug，便于团队内的协调。

　　（3）在编码过程中不可避免地要改动以前写好的代码，很可能引入错误，这时以前写好的单元测试代码能起来暴露和定位错误的作用。

使用boost.test的要点

　　（1）测试程序做为一个独立的程序运行，按testsuite和testcase将要测试的点组织成树形结构。

　　（2）Boost.test源代码中的第10个例子是一个接近实际应用的例子，但需要将本例分为三段来看：一是被测代码，二是测试代码，三是组织测试代码的主程序。

　　（3）单元测试是针对接口进行的，具有相同接口的类，应该可以共用同样的测试代码，要用这种方法提高测试代码的复用率。

　　（4）对一个具体类的测试代码组织成为一个testsuite，对一组类（一个模块）的测试代码组织成为一个更高一级的testsuite，并在模块的文件夹下安排一个main函数。

                                         

 

其他参考资料：

 

ACCU上一篇对比C++单元测试框架的文章

http://accu.org/index.php/journals/1326

 

开源测试方案汇总

http://www.opensourcetesting.org/

 

其他工具

Testframeworks like GNU/expectcan do the inspections automatically, but are overly complex forsimple testing.