《实时控制软件设计》之单元测试
《构建之法》第2章讨论了个人技术和流程，一个复杂的软件都是由若干个模块组成的，提高个人的技战术能力首先从编写一个稳定的模块开始，最基本的模块就是一个类。要保证自己提交的模块代码的质量得到保证，需要进行单元测试。2.1.2节给出了好的单元测试的标准：
- 在最基本的功能/参数上验证程序的正确性。
- 必须由最熟悉代码的人（程序作者）来写。
- 单元测试之后，机器状态保持不变。
- 单元测试要快。
- 单元测试应该产生可重复、一致的结果。
- 单元测试的独立性--不依赖于别的测试。
- 单元测试应该覆盖所有代码路径。
- 单元测试应该集成到自动测试的框架中。
- 单元测试必须和产品代码一起保存和维护。
本课程作业都基于C++代码编写，所以单元测试工具我们选用CPPUNIT，下面我们介绍使用方法。
要使用CPPUNIT库进行单元测试，首先需要在你的开发环境中安装CPPUNIT库，比如在Ubuntu Linux环境下，只需要执行如下命令
sudo apt-get install libcppunit-dev
就会把CPPUNIT的库文件及头文件安装到Linux的系统目录中，接下来在自己的测试代码中只要include相关的头文件，直接使用CPPUNIT函数了。
无论采用何种编译环境，总可以通过下载CPPUNIT的源代码（下载地址）进行编译和编译环境内的路径参数设置来完成环境配置。
可以通过编译如第1个最简单的例程来测试CPPUNIT是否安装好：
//mytest.cpp
#include <iostream>
#include <cppunit/TestCase.h>
class MyTest:public CppUnit::TestCase
{
public:
MyTest(std::string name): CppUnit::TestCase(name){}
void runTest()
{
CPPUNIT_ASSERT(1 == 1);
CPPUNIT_ASSERT_DOUBLES_EQUAL(2.11, 2.13, 0.01);
}
};
int main()
{
MyTest test1("Test1_Name");
std::cout << "This is the test: " << test1.getName() << std::endl;
std::cout << "The test has number:" << test1.countTestCases() << std::endl;
test1.runTest();
return 0;
}
在Ubuntu下可以用命令行编译该程序：
g++ -o mytest mytest.cpp -I/opt/local/include -L/opt/locallib -lcppunit -ldl
编译通过后运行该程序，会显示结果如下：
接下来我们分析下mytest.cpp的代码，里面定义了一个测试用例类MyTest，继承自CPPUNIT的TestCase类，并在runTest中定义了两个测试宏：
CPPUNIT_ASSERT(1 == 1);
CPPUNIT_ASSERT_DOUBLES_EQUAL(2.11, 2.13, 0.01);
第一个是调用CPPUNIT_ASSERT（condition），判断condition是否为真。
第二个是调用CPPUNIT_ASSERT_DOUBLES_EQUAL(expected, actual, delta)，判断两个浮点数expected和actual之间的差是否大于delta。
在主程序中创建MyTest的实例test1，并执行测试函数test1.runTest()。运行结果显示第二项测试没有通过。
上面是最简单的单元测试代码，但实际的单元测试往往不是直接使用 TestCase类，而是用TestFixture类，TestFixture类拥有TestSuite，每个TestSuite又可以拥有多个TestCase。下面是第2个示例代码：
#include <cppunit/extensions/HelperMacros.h>
#include <cppunit/ui/text/TestRunner.h>
class MyTests : public CppUnit::TestFixture
{
CPPUNIT_TEST_SUITE( MyTests );
CPPUNIT_TEST( testAdd );
CPPUNIT_TEST( testEquals );
CPPUNIT_TEST_SUITE_END();
double m_value1;
double m_value2;
public:
void setUp()
{
m_value1 = 2.0;
m_value2 = 3.0;
}
void tearDown()
{
}
void testAdd()
{
double result = m_value1 + m_value2;
CPPUNIT_ASSERT( result == 6.0 );
}
void testEquals()
{
long* l1 = new long(12);
long* l2 = new long(12);
CPPUNIT_ASSERT_EQUAL( 12, 12 );
CPPUNIT_ASSERT_EQUAL( 12L, 12L );
CPPUNIT_ASSERT_EQUAL( *l1, *l2 );
delete l1;
delete l2;
CPPUNIT_ASSERT( 12L == 12L );
CPPUNIT_ASSERT_EQUAL( 12, 13 );
CPPUNIT_ASSERT_DOUBLES_EQUAL( 12.0, 11.99, 0.5 );
}
};
int main()
{
CppUnit::TextUi::TestRunner runner;
runner.addTest( MyTests::suite() );
runner.run();
return 0;
}
分析下这个程序，我们发现在类MyTests的定义中采用了如下宏：
CPPUNIT_TEST_SUITE( MyTests );
CPPUNIT_TEST( testAdd );
CPPUNIT_TEST( testEquals );
CPPUNIT_TEST_SUITE_END();
其作用就是定义了两个TestCase: testAdd和testEquals，并把这两个TestCase添加到一个叫MyTests的TestSuite中去。
在主程序中实例化了一个TestRunner类对象runner，把MyTests这个测试用例集合添加到runner，然后调用runner.run()就自动执行所有的测试用例了。
从这个程序中，我们也可以体会到面向对象编程的一些思想方法。每次具体的单元测试的内容都是变化的，但是单元测试的基本原理和流程是不变的，我们的程序设计应该把不变的部分和变化的部分有效地区隔开来。在上面程序中，TestRunner对象相当于工厂里的质检员，他只按照标准的测试流程工作，所以我们不需要重新定义它，而是直接用CPPUNIT的类定义实例化一个对象，但TestRunner具体执行什么测试取决于我们提供给它什么测试用例集，所以我们只需要定义一个具体的测试用例集，并把该测试用例集传递给TestRunner，TestRunner通过调用它的标准作业流程run()，去执行每一个测试用例并返回结果。所以我们看主函数中的三行代码：
CppUnit::TextUi::TestRunner runner;
runner.addTest( MyTests::suite() );
runner.run();
第1行和第3行都不需要随着测试用例集的变化而变化，只有在第2行中，要把自定义的测试用例集名传递给TestRunner。
为了实现自动化的单元测试，我们希望当开发人员编写新的模块并增加或修改单元测试程序时，测试框架程序不随之变化。我们来看看KDL库里是如何实现这一点的。
framestest.hpp和framestest.cpp是一个具体的单元测试代码，里面具体的测试用例用来测试KDL的frames模块，如下面的一个测试宏：
CPPUNIT_ASSERT_DOUBLES_EQUAL((R*v).Norm(),v.Norm(),epsilon);
是为了测试一个向量v进行旋转操作R后是否保持模不变，从数学上讲模是完全不变的，但数值运算上肯定有精度问题，这里用epsilon来测试运算精度是否在epsilon范围内。
整个代码结构和上面第2个例程基本类似，稍有不同的是在framestest.cpp的开始部分，有一行代码
CPPUNIT_TEST_SUITE_REGISTRATION( FramesTest );
在KDL的tests目录中，有多个与FramesTest类似的单元测试代码，其结构和风格都类似，如JacobianTest，在其cpp实现文件中也有一行代码：
CPPUNIT_TEST_SUITE_REGISTRATION(JacobianTest);
test-runner.cpp则给出了测试框架程序：
#include <cppunit/XmlOutputter.h>
#include <cppunit/extensions/TestFactoryRegistry.h>
#include <cppunit/ui/text/TestRunner.h>
#include <iostream>
#include <fstream>
int main(int argc, char** argv)
{
// Get the top level suite from the registry
CppUnit::Test *suite = CppUnit::TestFactoryRegistry::getRegistry().makeTest();
// Adds the test to the list of test to run
CppUnit::TextUi::TestRunner runner;
runner.addTest( suite );
#ifndef TESTNAME
std::ofstream outputFile(std::string(suite->getName()+"-result.xml").c_str());
#else
std::ofstream outputFile((std::string(TESTNAME)+std::string("-result.xml")).c_str());
#endif
// Change the default outputter to a compiler error format outputter
runner.setOutputter( new CppUnit::XmlOutputter( &runner.result(),outputFile ) );
// Run the tests.
bool wasSucessful = runner.run();
outputFile.close();
// Return error code 1 if the one of test failed.
return wasSucessful ? 0 : 1;
}
主函数中有几行代码用于创建了一个log文件用于记录单元测试的结果，有两行代码
runner.addTest( suite );
bool wasSucessful = runner.run();
和第2个例子是完全相同的，不同的是在第2个例子中，我们需要直接把具体TestSuite名添加到runner中，但在这个框架程序中，使用了一行代码自动收集KDL所有的单元测试用例添加到suite中：
CppUnit::Test *suite = CppUnit::TestFactoryRegistry::getRegistry().makeTest();
这个就是设计模式中的工厂方法模式，每个具体的单元测试类通过CPPUNIT_TEST_SUITE_REGISTRATION宏把自己注册到工厂类中去，然后框架程序通过工厂类的方法自动创建所有的测试用例集对象，在项目开发过程中，test-runner.cpp作为测试框架程序不需要随着单元测试数量的变化进行代码的修改，可以自动执行并生成测试结果报告，这里也充分体现了设计模式的威力。
