单元测试已经越来越成为程序员工作密不可分的一部分了。在 C 里我们当然也是可以很方便地进行单元测试的。今天我就来介绍两个单元测试库一个是 Boost.Test [1]一个是 Catch2 [2]。Boost.Test单元测试库有很多我选择 Boost 的原因我在上一讲已经说过“如果我需要某个功能在标准库里没有在 Boost 里有我会很乐意直接使用 Boost 里的方案而非另外去查找。”再说Boost.Test 提供的功能还挺齐全的我需要的都有了。作为开胃小菜我们先看一个单元测试的小例子#define BOOST_TEST_MAIN #include boost/test/unit_test.hpp #include stdexcept void test(int n) { if (n 42) { return; } throw std::runtime_error( Not the answer); } BOOST_AUTO_TEST_CASE(my_test) { BOOST_TEST_MESSAGE(Testing); BOOST_TEST(1 1 2); BOOST_CHECK_THROW( test(41), std::runtime_error); BOOST_CHECK_NO_THROW(test(42)); int expected 5; BOOST_TEST(2 2 expected); BOOST_CHECK(2 2 expected); } BOOST_AUTO_TEST_CASE(null_test) { }我们从代码里可以看到我们在包含单元测试的头文件之前定义了 BOOST_TEST_MAIN。如果编译时用到了多个源文件只有一个应该定义该宏。多文件测试的时候我一般会考虑把这个定义这个宏加包含放在一个单独的文件里只有两行。我们用 BOOST_AUTO_TEST_CASE 来定义一个测试用例。一个测试用例里应当有多个测试语句如 BOOST_CHECK。我们用 BOOST_CHECK 或 BOOST_TEST 来检查一个应当成立的布尔表达式区别下面会讲。我们用 BOOST_CHECK_THROW 来检查一个应当抛出异常的语句。我们用 BOOST_CHECK_NO_THROW 来检查一个不应当抛出异常的语句。之前说过我们可以用下面的命令行来进行编译MSVCcl /DBOOST_TEST_DYN_LINK /EHsc /MD test.cppGCCg -DBOOST_TEST_DYN_LINK test.cpp -lboost_unit_test_frameworkClangclang -DBOOST_TEST_DYN_LINK test.cpp -lboost_unit_test_framework运行结果如下图所示我们现在能看到 BOOST_CHECK 和 BOOST_TEST 的区别了。后者是一个较新加入 Boost.Test 的宏能利用模板技巧来输出表达式的具体内容。但在某些情况下BOOST_TEST 试图输出表达式的内容会导致编译出错这时可以改用更简单的 BOOST_CHECK。不管是 BOOST_CHECK 还是 BOOST_TEST在测试失败时执行仍然会继续。在某些情况下一个测试失败后继续执行后面的测试已经没有意义这时我们就可以考虑使用 BOOST_REQUIRE 或 BOOST_TEST_REQUIRE——表达式一旦失败整个测试用例会停止执行但其他测试用例仍会正常执行。缺省情况下单元测试的输出只包含错误信息和结果摘要但输出的详细程度是可以通过命令行选项来进行控制的。如果我们在运行测试程序时加上命令行参数 --log_levelall或 -l all我们就可以得到下面这样更详尽的输出我们现在额外可以看到在进入、退出测试模块和用例时的提示BOOST_TEST_MESSAGE 的输出正常通过的测试的输出用例里无测试断言的警告使用 Windows 的同学如果运行了测试程序的话多半会惊恐地发现终端上的文字颜色已经发生了变化。这似乎是 Boost.Test 在 Windows 上特有的一个问题建议你把单元测试的色彩显示关掉。你可以在系统高级设置里添加下面这个环境变量也可以直接在命令行上输入set BOOST_TEST_COLOR_OUTPUT0下面我们看一个更真实的例子。假设我们有一个 split 函数定义如下template typename String, typename Delimiter class split_view { public: typedef typename String::value_type char_type; class iterator { … }; split_view(const String str, Delimiter delimiter); iterator begin() const; iterator end() const; vectorbasic_stringchar_type to_vector() const; vectorbasic_string_viewchar_type to_vector_sv() const; }; template typename String, typename Delimiter split_viewString, Delimiter split(const String str, Delimiter delimiter);这个函数的意图是把类似于字符串的类型string 或 string_view分割开并允许对分割的结果进行遍历。为了方便使用结果也可以直接转化成字符串的数组to_vector或字符串视图的数组to_vector_sv。我们不用关心这个函数是如何实现的我们就需要测试一下该如何写呢首先当然是写出一个测试用例的框架把试验的待分割字符串写进去BOOST_AUTO_TEST_CASE(split_test) { string_view str{ grant_typeclient_credential appid secretAPPSECRET}; }最简单直白的测试显然就是用 to_vector 或 to_vector_sv 来查看结果是否匹配了。这个非常容易加进去vectorstring split_result_expected{ , grant_typeclient_ credential, appid, secretAPPSECRET}; auto result split(str, ); auto result_s result.to_vector(); BOOST_TEST(result_s split_result_expected);如果 to_vector 实现正确的话我们现在运行程序就能在终端输出上看到*** No errors detected下面我们进一步检查 to_vector 和 to_vector_sv 的结果是否一致auto result_sv result.to_vector_sv(); BOOST_TEST_REQUIRE( result_s.size() result_sv.size()); { auto it result_sv.begin(); for (auto s : result_s) { BOOST_TEST(s *it); it; } }最后我们再测试可以遍历 result并且结果和之前的相同size_t i 0; auto it result.begin(); auto end result.end(); for (; it ! end i result_s.size(); it) { BOOST_TEST(*it result_s[i]); i; } BOOST_CHECK(it end);而这差不多就接近我实际的 split 测试代码了。完整代码可参见https://github.com/adah1972/nvwa/blob/master/test/boosttest_split.cppBoost.Test 产生的可执行代码支持很多命令行参数可以用 --help 命令行选项来查看。常用的有build_info 可用来展示构建信息color_output 可用来打开或关闭输出中的色彩log_format 可用来指定日志输出的格式包括纯文本、XML、JUnit 等log_level 可指定日志输出的级别有 all、test_suite、error、fatal_error、nothing 等一共 11 个级别run_test 可选择只运行指定的测试用例show_progress 可在测试时显示进度在测试数量较大时比较有用见下图我这儿只是个简单的介绍。完整的 Boost.Test 的功能介绍还是请你自行参看文档。Catch2说完了 Boost.Test我们再来看一下另外一个单元测试库Catch2。仍然是和上一讲里说的一样我要选择 Boost 之外的库一定有一个比较强的理由。Catch2 有着它自己独有的优点只需要单个头文件即可使用不需要安装和链接简单方便可选使用 BDDBehavior-Driven Development风格的分节形式测试失败可选直接进入调试器Windows 和 macOS 上我们拿前面 Boost.Test 的示例直接改造一下#define CATCH_CONFIG_MAIN #include catch.hpp #include stdexcept void test(int n) { if (n 42) { return; } throw std::runtime_error( Not the answer); } TEST_CASE(My first test, [my]) { INFO(Testing); CHECK(1 1 2); CHECK_THROWS_AS( test(41), std::runtime_error); CHECK_NOTHROW(test(42)); int expected 5; CHECK(2 2 expected); } TEST_CASE(A null test, [null]) { }可以看到两者之间的相似性非常多基本只是宏的名称变了一下。唯一值得一提的是测试用例的参数第一项是名字第二项是标签可以一个或多个。你除了可以直接在命令行上写测试的名字不需要选项来选择运行哪个测试外也可以写测试的标签来选择运行哪些测试。这是它在 Windows 下用 MSVC 编译的输出终端的色彩不会被搞乱。缺省的输出清晰程度相当不错。至少在 Windows 下它看起来可能是个比 Boost.Test 更好的选择。但反过来在浅色的终端里Catch2 的色彩不太友好。Boost.Test 在 Linux 和 macOS 下则不管终端的色彩设定都有比较友好的输出。和 Boost.Test 类似Catch2 的测试结果输出格式也是可以修改的。默认格式是纯文本但你可以通过使用 -r junit 来设成跟 JUnit 兼容的格式或使用 -r xml 输出成 Catch2 自己的 XML 格式。这方面它比 Boost.Test 明显易用的一个地方是格式参数大小写不敏感而在 Boost.Test 里你必须用全大写的形式如 -f JUNIT麻烦下面我们通过另外一个例子来展示一下所谓的 BDD [3] 风格的测试。BDD 风格的测试一般采用这样的结构Scenario场景我要做某某事Given给定已有的条件When当某个事件发生时Then那样就应该发生什么如果我们要测试一个容器那代码就应该是这个样子的SCENARIO(Int container can be accessed and modified, [container]) { GIVEN(A container with initialized items) { IntContainer c{1, 2, 3, 4, 5}; REQUIRE(c.size() 5); WHEN(I access existing items) { THEN(The items can be retrieved intact) { CHECK(c[0] 1); CHECK(c[1] 2); CHECK(c[2] 3); CHECK(c[3] 4); CHECK(c[4] 5); } } WHEN(I modify items) { c[1] -2; c[3] -4; THEN(Only modified items are changed) { CHECK(c[0] 1); CHECK(c[1] -2); CHECK(c[2] 3); CHECK(c[3] -4); CHECK(c[4] 5); } } } }你可以在程序前面加上类型定义来测试你自己的容器类或标准容器如 vector。这是一种非常直观的写测试的方式。正常情况下你当然应该看到All tests passed (12 assertions in 1 test case)如果你没有留意到的话在 GIVEN 里 WHEN 之前的代码是在每次 WHEN 之前都会执行一遍的。这也是 BDD 方式的一个非常方便的地方。如果测试失败我们就能看到类似下面这样的信息输出了我存心制造了一个错误如果没有失败的情况下想看到具体的测试内容可以传递参数 --success或 -s。如果你发现 Catch2 的编译速度有点慢的话那我得告诉你那是非常正常的。在你沮丧之前我还应该马上告诉你这在实际项目中完全不是一个问题。因为慢的原因通常主要是构建 Catch2 的主程序部分而这部份在项目中只需要做一次以后不会再有变动。你需要的是分离下面这部分代码在主程序里#define CATCH_CONFIG_MAIN #include catch.hpp只要这两行来单独编译 Catch2 的主程序部分。你的实际测试代码里则不要再定义 CATCH_CONFIG_MAIN 了。你会发现这样一分离后编译速度会大大加快。事实上如果 Catch2 的主程序部分不需要编译的话Catch2 的测试用例的编译速度在我的机器上比 Boost.Test 的还要快。我觉得 Catch2 是一个很现代、很好用的测试框架。它的宏更简单一个 CHECK 可以替代 Boost.Test 中的 BOOST_TEST 和 BOOST_CHECK也没有 BOOST_TEST 在某些情况下不能用、必须换用 BOOST_CHECK 的问题。对于一个新项目使用 Catch2 应该是件更简单、更容易上手的事——尤其如果你在 Windows 上开发的话。目前在 GitHub 上Catch2 的收藏数超过一万复刻fork数达到一千七也已经足以证明它的流行程度。内容小结今天我们介绍了两个单元测试库Boost.Test 和 Catch2。整体上来看这两个都是很优秀的单元测试框架可以满足日常开发的需要。参考资料[1] Gennadiy Rozental and Raffi Enficiaud, Boost.Test. https://www.boost.org/doc/libs/release/libs/test/doc/html/index.html [2] Two Blue Cubes Ltd., Catch2. https://github.com/catchorg/Catch2 [3] Wikipedia, “Behavior-driven development”. https://en.wikipedia.org/wiki/Behavior-driven_development 现代C++：C++里如何进行单元测试？
单元测试已经越来越成为程序员工作密不可分的一部分了。在 C 里我们当然也是可以很方便地进行单元测试的。今天我就来介绍两个单元测试库一个是 Boost.Test [1]一个是 Catch2 [2]。Boost.Test单元测试库有很多我选择 Boost 的原因我在上一讲已经说过“如果我需要某个功能在标准库里没有在 Boost 里有我会很乐意直接使用 Boost 里的方案而非另外去查找。”再说Boost.Test 提供的功能还挺齐全的我需要的都有了。作为开胃小菜我们先看一个单元测试的小例子#define BOOST_TEST_MAIN #include boost/test/unit_test.hpp #include stdexcept void test(int n) { if (n 42) { return; } throw std::runtime_error( Not the answer); } BOOST_AUTO_TEST_CASE(my_test) { BOOST_TEST_MESSAGE(Testing); BOOST_TEST(1 1 2); BOOST_CHECK_THROW( test(41), std::runtime_error); BOOST_CHECK_NO_THROW(test(42)); int expected 5; BOOST_TEST(2 2 expected); BOOST_CHECK(2 2 expected); } BOOST_AUTO_TEST_CASE(null_test) { }我们从代码里可以看到我们在包含单元测试的头文件之前定义了 BOOST_TEST_MAIN。如果编译时用到了多个源文件只有一个应该定义该宏。多文件测试的时候我一般会考虑把这个定义这个宏加包含放在一个单独的文件里只有两行。我们用 BOOST_AUTO_TEST_CASE 来定义一个测试用例。一个测试用例里应当有多个测试语句如 BOOST_CHECK。我们用 BOOST_CHECK 或 BOOST_TEST 来检查一个应当成立的布尔表达式区别下面会讲。我们用 BOOST_CHECK_THROW 来检查一个应当抛出异常的语句。我们用 BOOST_CHECK_NO_THROW 来检查一个不应当抛出异常的语句。之前说过我们可以用下面的命令行来进行编译MSVCcl /DBOOST_TEST_DYN_LINK /EHsc /MD test.cppGCCg -DBOOST_TEST_DYN_LINK test.cpp -lboost_unit_test_frameworkClangclang -DBOOST_TEST_DYN_LINK test.cpp -lboost_unit_test_framework运行结果如下图所示我们现在能看到 BOOST_CHECK 和 BOOST_TEST 的区别了。后者是一个较新加入 Boost.Test 的宏能利用模板技巧来输出表达式的具体内容。但在某些情况下BOOST_TEST 试图输出表达式的内容会导致编译出错这时可以改用更简单的 BOOST_CHECK。不管是 BOOST_CHECK 还是 BOOST_TEST在测试失败时执行仍然会继续。在某些情况下一个测试失败后继续执行后面的测试已经没有意义这时我们就可以考虑使用 BOOST_REQUIRE 或 BOOST_TEST_REQUIRE——表达式一旦失败整个测试用例会停止执行但其他测试用例仍会正常执行。缺省情况下单元测试的输出只包含错误信息和结果摘要但输出的详细程度是可以通过命令行选项来进行控制的。如果我们在运行测试程序时加上命令行参数 --log_levelall或 -l all我们就可以得到下面这样更详尽的输出我们现在额外可以看到在进入、退出测试模块和用例时的提示BOOST_TEST_MESSAGE 的输出正常通过的测试的输出用例里无测试断言的警告使用 Windows 的同学如果运行了测试程序的话多半会惊恐地发现终端上的文字颜色已经发生了变化。这似乎是 Boost.Test 在 Windows 上特有的一个问题建议你把单元测试的色彩显示关掉。你可以在系统高级设置里添加下面这个环境变量也可以直接在命令行上输入set BOOST_TEST_COLOR_OUTPUT0下面我们看一个更真实的例子。假设我们有一个 split 函数定义如下template typename String, typename Delimiter class split_view { public: typedef typename String::value_type char_type; class iterator { … }; split_view(const String str, Delimiter delimiter); iterator begin() const; iterator end() const; vectorbasic_stringchar_type to_vector() const; vectorbasic_string_viewchar_type to_vector_sv() const; }; template typename String, typename Delimiter split_viewString, Delimiter split(const String str, Delimiter delimiter);这个函数的意图是把类似于字符串的类型string 或 string_view分割开并允许对分割的结果进行遍历。为了方便使用结果也可以直接转化成字符串的数组to_vector或字符串视图的数组to_vector_sv。我们不用关心这个函数是如何实现的我们就需要测试一下该如何写呢首先当然是写出一个测试用例的框架把试验的待分割字符串写进去BOOST_AUTO_TEST_CASE(split_test) { string_view str{ grant_typeclient_credential appid secretAPPSECRET}; }最简单直白的测试显然就是用 to_vector 或 to_vector_sv 来查看结果是否匹配了。这个非常容易加进去vectorstring split_result_expected{ , grant_typeclient_ credential, appid, secretAPPSECRET}; auto result split(str, ); auto result_s result.to_vector(); BOOST_TEST(result_s split_result_expected);如果 to_vector 实现正确的话我们现在运行程序就能在终端输出上看到*** No errors detected下面我们进一步检查 to_vector 和 to_vector_sv 的结果是否一致auto result_sv result.to_vector_sv(); BOOST_TEST_REQUIRE( result_s.size() result_sv.size()); { auto it result_sv.begin(); for (auto s : result_s) { BOOST_TEST(s *it); it; } }最后我们再测试可以遍历 result并且结果和之前的相同size_t i 0; auto it result.begin(); auto end result.end(); for (; it ! end i result_s.size(); it) { BOOST_TEST(*it result_s[i]); i; } BOOST_CHECK(it end);而这差不多就接近我实际的 split 测试代码了。完整代码可参见https://github.com/adah1972/nvwa/blob/master/test/boosttest_split.cppBoost.Test 产生的可执行代码支持很多命令行参数可以用 --help 命令行选项来查看。常用的有build_info 可用来展示构建信息color_output 可用来打开或关闭输出中的色彩log_format 可用来指定日志输出的格式包括纯文本、XML、JUnit 等log_level 可指定日志输出的级别有 all、test_suite、error、fatal_error、nothing 等一共 11 个级别run_test 可选择只运行指定的测试用例show_progress 可在测试时显示进度在测试数量较大时比较有用见下图我这儿只是个简单的介绍。完整的 Boost.Test 的功能介绍还是请你自行参看文档。Catch2说完了 Boost.Test我们再来看一下另外一个单元测试库Catch2。仍然是和上一讲里说的一样我要选择 Boost 之外的库一定有一个比较强的理由。Catch2 有着它自己独有的优点只需要单个头文件即可使用不需要安装和链接简单方便可选使用 BDDBehavior-Driven Development风格的分节形式测试失败可选直接进入调试器Windows 和 macOS 上我们拿前面 Boost.Test 的示例直接改造一下#define CATCH_CONFIG_MAIN #include catch.hpp #include stdexcept void test(int n) { if (n 42) { return; } throw std::runtime_error( Not the answer); } TEST_CASE(My first test, [my]) { INFO(Testing); CHECK(1 1 2); CHECK_THROWS_AS( test(41), std::runtime_error); CHECK_NOTHROW(test(42)); int expected 5; CHECK(2 2 expected); } TEST_CASE(A null test, [null]) { }可以看到两者之间的相似性非常多基本只是宏的名称变了一下。唯一值得一提的是测试用例的参数第一项是名字第二项是标签可以一个或多个。你除了可以直接在命令行上写测试的名字不需要选项来选择运行哪个测试外也可以写测试的标签来选择运行哪些测试。这是它在 Windows 下用 MSVC 编译的输出终端的色彩不会被搞乱。缺省的输出清晰程度相当不错。至少在 Windows 下它看起来可能是个比 Boost.Test 更好的选择。但反过来在浅色的终端里Catch2 的色彩不太友好。Boost.Test 在 Linux 和 macOS 下则不管终端的色彩设定都有比较友好的输出。和 Boost.Test 类似Catch2 的测试结果输出格式也是可以修改的。默认格式是纯文本但你可以通过使用 -r junit 来设成跟 JUnit 兼容的格式或使用 -r xml 输出成 Catch2 自己的 XML 格式。这方面它比 Boost.Test 明显易用的一个地方是格式参数大小写不敏感而在 Boost.Test 里你必须用全大写的形式如 -f JUNIT麻烦下面我们通过另外一个例子来展示一下所谓的 BDD [3] 风格的测试。BDD 风格的测试一般采用这样的结构Scenario场景我要做某某事Given给定已有的条件When当某个事件发生时Then那样就应该发生什么如果我们要测试一个容器那代码就应该是这个样子的SCENARIO(Int container can be accessed and modified, [container]) { GIVEN(A container with initialized items) { IntContainer c{1, 2, 3, 4, 5}; REQUIRE(c.size() 5); WHEN(I access existing items) { THEN(The items can be retrieved intact) { CHECK(c[0] 1); CHECK(c[1] 2); CHECK(c[2] 3); CHECK(c[3] 4); CHECK(c[4] 5); } } WHEN(I modify items) { c[1] -2; c[3] -4; THEN(Only modified items are changed) { CHECK(c[0] 1); CHECK(c[1] -2); CHECK(c[2] 3); CHECK(c[3] -4); CHECK(c[4] 5); } } } }你可以在程序前面加上类型定义来测试你自己的容器类或标准容器如 vector。这是一种非常直观的写测试的方式。正常情况下你当然应该看到All tests passed (12 assertions in 1 test case)如果你没有留意到的话在 GIVEN 里 WHEN 之前的代码是在每次 WHEN 之前都会执行一遍的。这也是 BDD 方式的一个非常方便的地方。如果测试失败我们就能看到类似下面这样的信息输出了我存心制造了一个错误如果没有失败的情况下想看到具体的测试内容可以传递参数 --success或 -s。如果你发现 Catch2 的编译速度有点慢的话那我得告诉你那是非常正常的。在你沮丧之前我还应该马上告诉你这在实际项目中完全不是一个问题。因为慢的原因通常主要是构建 Catch2 的主程序部分而这部份在项目中只需要做一次以后不会再有变动。你需要的是分离下面这部分代码在主程序里#define CATCH_CONFIG_MAIN #include catch.hpp只要这两行来单独编译 Catch2 的主程序部分。你的实际测试代码里则不要再定义 CATCH_CONFIG_MAIN 了。你会发现这样一分离后编译速度会大大加快。事实上如果 Catch2 的主程序部分不需要编译的话Catch2 的测试用例的编译速度在我的机器上比 Boost.Test 的还要快。我觉得 Catch2 是一个很现代、很好用的测试框架。它的宏更简单一个 CHECK 可以替代 Boost.Test 中的 BOOST_TEST 和 BOOST_CHECK也没有 BOOST_TEST 在某些情况下不能用、必须换用 BOOST_CHECK 的问题。对于一个新项目使用 Catch2 应该是件更简单、更容易上手的事——尤其如果你在 Windows 上开发的话。目前在 GitHub 上Catch2 的收藏数超过一万复刻fork数达到一千七也已经足以证明它的流行程度。内容小结今天我们介绍了两个单元测试库Boost.Test 和 Catch2。整体上来看这两个都是很优秀的单元测试框架可以满足日常开发的需要。参考资料[1] Gennadiy Rozental and Raffi Enficiaud, Boost.Test. https://www.boost.org/doc/libs/release/libs/test/doc/html/index.html [2] Two Blue Cubes Ltd., Catch2. https://github.com/catchorg/Catch2 [3] Wikipedia, “Behavior-driven development”. https://en.wikipedia.org/wiki/Behavior-driven_development