25 | 兩個單元測試庫：C++里如何進行單元測試?
你好，我是吳詠煒。
單元測試已經(jīng)越來越成為程序員工作密不可分的一部分了。在 C++ 里，我們當然也是可以很方便地進行單元測試的。今天，我就來介紹兩個單元測試庫：一個是 Boost.Test [1]，一個是 Catch2 [2]。
Boost.Test
單元測試庫有很多，我選擇 Boost 的原因我在上一講已經(jīng)說過：“如果我需要某個功能，在標準庫里沒有，在 Boost 里有，我會很樂意直接使用 Boost 里的方案，而非另外去查找?！痹僬f，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。如果編譯時用到了多個源文件，只有一個應(yīng)該定義該宏。多文件測試的時候，我一般會考慮把這個定義這個宏加包含放在一個單獨的文件里（只有兩行）。 - 我們用
BOOST_AUTO_TEST_CASE來定義一個測試用例。一個測試用例里應(yīng)當有多個測試語句（如BOOST_CHECK）。 - 我們用
BOOST_CHECK或BOOST_TEST來檢查一個應(yīng)當成立的布爾表達式（區(qū)別下面會講）。 - 我們用
BOOST_CHECK_THROW來檢查一個應(yīng)當拋出異常的語句。 - 我們用
BOOST_CHECK_NO_THROW來檢查一個不應(yīng)當拋出異常的語句。
如 [第 21 講] 所述，我們可以用下面的命令行來進行編譯：
- MSVC：
cl /DBOOST_TEST_DYN_LINK /EHsc /MD test.cpp - GCC：
g++ -DBOOST_TEST_DYN_LINK test.cpp -lboost_unit_test_framework - Clang：
clang++ -DBOOST_TEST_DYN_LINK test.cpp -lboost_unit_test_framework
運行結(jié)果如下圖所示：
我們現(xiàn)在能看到 BOOST_CHECK 和 BOOST_TEST 的區(qū)別了。后者是一個較新加入 Boost.Test 的宏，能利用模板技巧來輸出表達式的具體內(nèi)容。但在某些情況下， BOOST_TEST 試圖輸出表達式的內(nèi)容會導(dǎo)致編譯出錯，這時可以改用更簡單的 BOOST_CHECK。
不管是 BOOST_CHECK 還是 BOOST_TEST，在測試失敗時，執(zhí)行仍然會繼續(xù)。在某些情況下，一個測試失敗后繼續(xù)執(zhí)行后面的測試已經(jīng)沒有意義，這時，我們就可以考慮使用 BOOST_REQUIRE 或 BOOST_TEST_REQUIRE——表達式一旦失敗，整個測試用例會停止執(zhí)行（但其他測試用例仍會正常執(zhí)行）。
缺省情況下單元測試的輸出只包含錯誤信息和結(jié)果摘要，但輸出的詳細程度是可以通過命令行選項來進行控制的。如果我們在運行測試程序時加上命令行參數(shù) --log_level=all（或 -l all），我們就可以得到下面這樣更詳盡的輸出：
我們現(xiàn)在額外可以看到：
- 在進入、退出測試模塊和用例時的提示
-
BOOST_TEST_MESSAGE的輸出 - 正常通過的測試的輸出
- 用例里無測試斷言的警告
使用 Windows 的同學(xué)如果運行了測試程序的話，多半會驚恐地發(fā)現(xiàn)終端上的文字顏色已經(jīng)發(fā)生了變化。這似乎是 Boost.Test 在 Windows 上特有的一個問題：建議你把單元測試的色彩顯示關(guān)掉。你可以在系統(tǒng)高級設(shè)置里添加下面這個環(huán)境變量，也可以直接在命令行上輸入：
set BOOST_TEST_COLOR_OUTPUT=0
下面我們看一個更真實的例子。
假設(shè)我們有一個 split 函數(shù)，定義如下：
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;
vector<basic_string<char_type>>
to_vector() const;
vector<basic_string_view<char_type>>
to_vector_sv() const;
};
template <typename String,
typename Delimiter>
split_view<String, Delimiter>
split(const String& str,
Delimiter delimiter);
這個函數(shù)的意圖是把類似于字符串的類型（ string 或 string_view）分割開，并允許對分割的結(jié)果進行遍歷。為了方便使用，結(jié)果也可以直接轉(zhuǎn)化成字符串的數(shù)組（ to_vector）或字符串視圖的數(shù)組（ to_vector_sv）。我們不用關(guān)心這個函數(shù)是如何實現(xiàn)的，我們就需要測試一下，該如何寫呢？
首先，當然是寫出一個測試用例的框架，把試驗的待分割字符串寫進去：
BOOST_AUTO_TEST_CASE(split_test)
{
string_view str{
"&grant_type=client_credential"
"&appid="
"&secret=APPSECRET"};
}
最簡單直白的測試，顯然就是用 to_vector 或 to_vector_sv 來查看結(jié)果是否匹配了。這個非常容易加進去：
vector<string>
split_result_expected{
"",
"grant_type=client_"
"credential",
"appid=",
"secret=APPSECRET"};
auto result = split(str, '&');
auto result_s =
result.to_vector();
BOOST_TEST(result_s ==
split_result_expected);
如果 to_vector 實現(xiàn)正確的話，我們現(xiàn)在運行程序就能在終端輸出上看到：
*** No errors detected
下面，我們進一步檢查 to_vector 和 to_vector_sv 的結(jié)果是否一致：
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，并且結(jié)果和之前的相同：
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.cpp
Boost.Test 產(chǎn)生的可執(zhí)行代碼支持很多命令行參數(shù)，可以用 --help 命令行選項來查看。常用的有：
-
build_info可用來展示構(gòu)建信息 -
color_output可用來打開或關(guān)閉輸出中的色彩 -
log_format可用來指定日志輸出的格式，包括純文本、XML、JUnit 等 -
log_level可指定日志輸出的級別，有 all、test_suite、error、fatal_error、nothing 等一共 11 個級別 -
run_test可選擇只運行指定的測試用例 -
show_progress可在測試時顯示進度，在測試數(shù)量較大時比較有用（見下圖）
我這兒只是個簡單的介紹。完整的 Boost.Test 的功能介紹還是請你自行參看文檔。
Catch2
說完了 Boost.Test，我們再來看一下另外一個單元測試庫，Catch2。仍然是和上一講里說的一樣，我要選擇 Boost 之外的庫，一定有一個比較強的理由。Catch2 有著它自己獨有的優(yōu)點：
- 只需要單個頭文件即可使用，不需要安裝和鏈接，簡單方便
- 可選使用 BDD（Behavior-Driven Development）風(fēng)格的分節(jié)形式
- 測試失敗可選直接進入調(diào)試器（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]")
{
}
可以看到，兩者之間的相似性非常多，基本只是宏的名稱變了一下。唯一值得一提的，是測試用例的參數(shù)：第一項是名字，第二項是標簽，可以一個或多個。你除了可以直接在命令行上寫測試的名字（不需要選項）來選擇運行哪個測試外，也可以寫測試的標簽來選擇運行哪些測試。
這是它在 Windows 下用 MSVC 編譯的輸出：
終端的色彩不會被搞亂。缺省的輸出清晰程度相當不錯。至少在 Windows 下，它看起來可能是個比 Boost.Test 更好的選擇。但反過來，在淺色的終端里，Catch2 的色彩不太友好。Boost.Test 在 Linux 和 macOS 下則不管終端的色彩設(shè)定，都有比較友好的輸出。
和 Boost.Test 類似，Catch2 的測試結(jié)果輸出格式也是可以修改的。默認格式是純文本，但你可以通過使用 -r junit 來設(shè)成跟 JUnit 兼容的格式，或使用 -r xml 輸出成 Catch2 自己的 XML 格式。這方面，它比 Boost.Test 明顯易用的一個地方是格式參數(shù)大小寫不敏感，而在 Boost.Test 里你必須用全大寫的形式，如 -f JUNIT，麻煩！
下面我們通過另外一個例子來展示一下所謂的 BDD [3] 風(fēng)格的測試。
BDD 風(fēng)格的測試一般采用這樣的結(jié)構(gòu)：
- Scenario：場景，我要做某某事
- Given：給定，已有的條件
- When：當，某個事件發(fā)生時
- Then：那樣，就應(yīng)該發(fā)生什么
如果我們要測試一個容器，那代碼就應(yīng)該是這個樣子的：
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<int>）。這是一種非常直觀的寫測試的方式。正常情況下，你當然應(yīng)該看到：
All tests passed (12 assertions in 1 test case)
如果你沒有留意到的話，在 GIVEN 里 WHEN 之前的代碼是在每次 WHEN 之前都會執(zhí)行一遍的。這也是 BDD 方式的一個非常方便的地方。
如果測試失敗，我們就能看到類似下面這樣的信息輸出了（我存心制造了一個錯誤）：
如果沒有失敗的情況下，想看到具體的測試內(nèi)容，可以傳遞參數(shù) --success（或 -s）。
如果你發(fā)現(xiàn) Catch2 的編譯速度有點慢的話，那我得告訴你，那是非常正常的。在你沮喪之前，我還應(yīng)該馬上告訴你，這在實際項目中完全不是一個問題。因為慢的原因通常主要是構(gòu)建 Catch2 的主程序部分，而這部份在項目中只需要做一次，以后不會再有變動。你需要的是分離下面這部分代碼在主程序里：
#define CATCH_CONFIG_MAIN
#include "catch.hpp"
只要這兩行，來單獨編譯 Catch2 的主程序部分。你的實際測試代碼里，則不要再定義 CATCH_CONFIG_MAIN 了。你會發(fā)現(xiàn)，這樣一分離后，編譯速度會大大加快。事實上，如果 Catch2 的主程序部分不需要編譯的話，Catch2 的測試用例的編譯速度在我的機器上比 Boost.Test 的還要快。
我覺得 Catch2 是一個很現(xiàn)代、很好用的測試框架。它的宏更簡單，一個 CHECK 可以替代 Boost.Test 中的 BOOST_TEST 和 BOOST_CHECK，也沒有 BOOST_TEST 在某些情況下不能用、必須換用 BOOST_CHECK 的問題。對于一個新項目，使用 Catch2 應(yīng)該是件更簡單、更容易上手的事——尤其如果你在 Windows 上開發(fā)的話。
目前，在 GitHub 上，Catch2 的收藏數(shù)超過一萬，復(fù)刻（fork）數(shù)達到一千七，也已經(jīng)足以證明它的流行程度。
內(nèi)容小結(jié)
今天我們介紹了兩個單元測試庫，Boost.Test 和 Catch2。整體上來看，這兩個都是很優(yōu)秀的單元測試框架，可以滿足日常開發(fā)的需要。
課后思考
請你自己試驗一下本講中的例子，來制造一些成功和失敗的情況。使用一下，才能更容易確定哪一個更適合你的需求。
參考資料
[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文章來源：http://www.zghlxwxcb.cn/news/detail-722853.html
[3] Wikipedia, “Behavior-driven development”. https://en.wikipedia.org/wiki/Behavior-driven_development文章來源地址http://www.zghlxwxcb.cn/news/detail-722853.html
到了這里，關(guān)于現(xiàn)代C++編程實戰(zhàn)25-兩個單元測試庫：C++里如何進行單元測試的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
