| BOOST_FIXTURE_TEST_SUITE(test_suite, MyFixture ); BOOST_AUTO_TEST_CASE (test_case1) { BOOST_CHECK(i==5); } BOOST_AUTO_TEST_CASE(test_case2) { BOOST_CHECK(++i==6); } BOOST_AUTO_TEST_SUITE_END() |
使用宏BOOST_GLOBAL_FIXTURE(MyFixture);将MyFixture声明为全局夹具，即可和MainTestSuite一起使用。
3.7 Boost.Test使用
对已经完成的项目做单元测试，假定该项目具有很好的测试性：
1） 对项目中的每个类对象创建一个测试套件，一个测试套件对应一个cpp文件。对类的每个类方法创建一个测试用例，这些测试用例均包含上前面的测试套件中。每个测试用例可以有多个测试断言，对该方法进行充分测试。
2） 在测试主文件中定义宏BOOST_TEST_MODULE，并包含所有的测试套件文件。
3） Linux下，将被测试项目编译成静态库（将main函数外的所有文件编译打包）供测试项目连接。Window下为测试项目做静态库工程，设置测试工程依赖该工程。并将头文件路径设置正确，即可编译运行。
附件为一示例项目以及对应单元测试工程举例，项目目录下make编译生成静态库以及可执行程序，test目录下make生成单元测试可执行程序。（略）
4 实行单元测试
4.1 现实困难
1、 内部依赖问题
类之间相互协作共同完成功能，类之间的依赖必不可少。为了测试某个类，必须实例化它依赖的类，而它依赖的类又可能依赖其他类，因此必须实例化其他类。如此一环扣一环，可能把整个项目大部分类都包含在了这次测试中，最后做的不是单元测试，而是挂着单元测试外壳的集成测试。
2、 外部依赖问题
很多项目，尤其是我们的网络应用服务器，运行期间需要依赖外部的其他服务器或者数据库或者本地的文件系统。而对很多外部的依赖很难模拟，或者说模拟成本太高，往往让测试者望而却步。
3、 函数本身问题
项目中的很多或者可能是大部分函数，是没有明确返回值或者无异常抛出，而只是和其他外设交互。难于使用测试断言判定。
以上造成很难将某个类从项目中隔离出来，难以设置单元测试点。
4.2 解决困难
上述困难均为依赖造成。
1、内部解依赖
对被测代码进行解依赖，强化设计，减少耦合，提高代码可测性。解依赖的过程也即为对代码重构过程，减少类间耦合，制造接口层。常用手段有：虚函数、函数指针、传递参数等方式。而对于难于进行解依赖情况，就要考虑提取分化重写方法。
2、写桩代码模拟外部环境
单元测试不能直接依赖外部环境，必须写桩代码模拟。而外部环境的可模拟性与内部解依赖紧密相关。对于外部的随机性和各种不确定性，桩代码必须尽可能模拟。
3、开辟访问类私有属性通道
有些类方法虽然没有明确返回值，但可能修改类的内部状态，可以通过判断类的私有属性来判定类方法的执行情况。可以给类增加Get()方法或者将私有属性设置为protected。
更重要的是在代码开发期，引入TDD思维，强化设计，提高代码可测性，提高代码的整体质量。
