写完功能代码之后不写测试，是很多C++项目质量失控的开始。Boost.Test是Boost家族中专门负责单元测试的组件，它历史悠久、文档完善，被许多大型开源项目用作默认测试框架。这篇文章带你从零开始搭建Boost.Test环境，编写测试用例、组织测试套件、使用夹具共享数据，最后把测试接入CMake构建流程，形成一套完整的自动化测试方案。
一、环境搭建与最小可运行示例
Boost.Test既支持头文件方式使用，也可以编译成静态库链接。头文件方式最简单，只需包含<boost/test/unit_test.hpp>，并定义宏BOOST_TEST_MODULE即可，适合中小型项目快速上手。当测试数量增多、编译时间变长时，再切换到库链接方式可以获得更快的编译速度。
先看一个最小的例子。注意BOOST_TEST_MODULE必须在包含头文件之前定义，它告诉框架当前编译单元是主测试模块，框架会自动生成main函数，省去手写入口的麻烦。
#define BOOST_TEST_MODULE MyFirstTest
#include <boost/test/unit_test.hpp>
int Add(int a, int b)
{
return a + b;
}
BOOST_AUTO_TEST_CASE(AddTest)
{
BOOST_TEST(Add(1, 2) == 3);
BOOST_TEST(Add(-1, 1) == 0);
}
编译时如果采用头文件方式，可以加上-DBOOST_TEST_DYN_LINK并链接boost_unit_test_framework库。以g++为例，命令大致是g++ test.cpp -lboost_unit_test_framework -o test。运行生成的可执行文件，框架会输出测试结果摘要，包括通过的用例数、失败的断言数等信息。如果某个断言失败，输出中会包含文件名和行号，方便快速定位。
二、断言宏的使用：从普通比较到异常检测
Boost.Test提供了丰富的断言宏，最推荐使用的是BOOST_TEST，它是一个通用断言，能自动识别比较表达式并输出更友好的失败信息。例如BOOST_TEST(a == b)失败时，会同时打印a和b的实际值，而不只是告诉你断言失败了。
除了通用断言，框架还有一系列专用宏，各自适用不同场景：
BOOST_CHECK：检查条件，失败时记录错误但继续执行后续语句，适合多个相互独立的检查写在同一个用例里。BOOST_REQUIRE：检查条件，失败时立即终止当前用例，适合前置条件校验，比如指针非空判断。BOOST_CHECK_EQUAL：比较两个值是否相等，失败时打印两个操作数的值。BOOST_CHECK_THROW：验证表达式抛出指定类型的异常。BOOST_CHECK_NO_THROW：验证表达式不抛出任何异常。
下面的例子演示了异常检测的写法。假设有一个函数在参数非法时抛出std::invalid_argument，测试就应该验证这个行为确实发生：
#include <boost/test/unit_test.hpp>
#include <stdexcept>
double Divide(double a, double b)
{
if (b == 0.0)
{
throw std::invalid_argument("divider is zero");
}
return a / b;
}
BOOST_AUTO_TEST_CASE(DivideTest)
{
BOOST_TEST(Divide(6.0, 3.0) == 2.0);
BOOST_CHECK_THROW(Divide(1.0, 0.0), std::invalid_argument);
BOOST_CHECK_NO_THROW(Divide(1.0, 2.0));
}
对于浮点数比较，直接用==容易因精度问题误报。Boost.Test提供了按相对误差或绝对误差比较的机制，例如boost::test_tools::tolerance，写法是BOOST_TEST(x == y, boost::test_tools::tolerance(1e-9))，这样两个浮点数在允许误差范围内即判定相等，是处理科学计算代码测试的常用手段。
三、测试套件与夹具的组织方式
当测试用例数量增长后，需要用测试套件分组管理。Boost.Test支持自动套件和手动套件两种风格。自动套件通过BOOST_AUTO_TEST_SUITE和BOOST_AUTO_TEST_SUITE_END配对使用，中间的所有用例自动归属该套件：
#define BOOST_TEST_MODULE SuiteDemo
#include <boost/test/unit_test.hpp>
BOOST_AUTO_TEST_SUITE(MathTests)
BOOST_AUTO_TEST_CASE(AddTest)
{
BOOST_TEST(1 + 1 == 2);
}
BOOST_AUTO_TEST_CASE(MultiplyTest)
{
BOOST_TEST(2 * 3 == 6);
}
BOOST_AUTO_TEST_SUITE_END()
套件可以嵌套，形成树状结构，配合运行时的--run_test=套件名/用例名参数，可以只执行某个子集的测试，这在调试单个失败用例时非常高效。
夹具（Fixture）解决的是多个用例共享初始化代码的问题。最直接的方式是使用BOOST_FIXTURE_TEST_CASE，为单个用例绑定一个夹具类型，该类型的构造函数在用例执行前调用，析构函数在用例结束后调用，符合RAII风格：
#include <boost/test/unit_test.hpp>
#include <vector>
struct VectorFixture
{
std::vector<int> data;
VectorFixture() : data{1, 2, 3, 4, 5}
{
// 构造时准备测试数据
}
};
BOOST_FIXTURE_TEST_CASE(SizeTest, VectorFixture)
{
BOOST_TEST(data.size() == 5);
}
BOOST_FIXTURE_TEST_CASE(SumTest, VectorFixture)
{
int sum = 0;
for (int v : data)
{
sum += v;
}
BOOST_TEST(sum == 15);
}
每个用例都会得到一份全新的夹具实例，用例之间互不干扰，这是单元测试的重要原则。如果希望整个套件共享一个夹具，可以用BOOST_AUTO_TEST_SUITE配合夹具参数的形式，但要谨慎使用，共享状态容易让测试产生隐式依赖，排查问题时会很痛苦。
四、命令行控制与CMake集成
测试可执行文件本身支持丰富的命令行参数。常用的包括--log_level=all输出详细日志，--run_test=MathTests只运行指定套件，--show_progress=yes显示执行进度，以及--build_info=yes打印编译器等环境信息。在持续集成环境中，通常加上--log_format=XML --log_sink=result.xml生成机器可读的报告，方便与CI平台集成展示。
在CMake工程中集成Boost.Test非常方便。CMake自带BoostTest的查找模块，结合enable_testing和add_test命令即可把测试纳入ctest体系：
cmake_minimum_required(VERSION 3.16)
project(MyProjectTests CXX)
enable_testing()
find_package(Boost 1.70 REQUIRED COMPONENTS unit_test_framework)
add_executable(unit_tests
test_add.cpp
test_divide.cpp
)
target_link_libraries(unit_tests PRIVATE Boost::unit_test_framework)
add_test(NAME UnitTests COMMAND unit_tests)
配置完成后，执行cmake --build .编译，再运行ctest --output-on-failure即可自动执行所有测试，失败时输出详细日志。这种方式的好处是测试完全融入日常构建流程，每次提交代码前跑一遍ctest，就能及时发现回归问题。
总的来说，Boost.Test的学习曲线平缓，断言信息详细，夹具机制灵活，配合CMake和ctest可以低成本搭建一套持续可用的测试基础设施。建议从核心模块的纯函数开始补测试，逐步覆盖异常分支和边界条件，让测试真正成为重构和迭代时的安全网。
Boost.TestC++单元测试测试框架修改时间：2026-09-03 10:45:09