摘要：如果能够让代码在编译的时候，自动完成白盒测试，这不是天方夜谭。
白盒测试也叫开发者测试，是对特定代码函数或模块所进行的功能测试。当前主流的白盒测试方法是：先针对仿真或者生产环境编译出可执行文件，然后运行得到测试结果。这种方法有 3 个问题：
1. 可能需要专门针对白盒测试额外做一次构建。这是因为仿真环境和实际运行环境可能是不同的硬件平台，而且白盒测试需要额外链接一些库（比如 GTest），构建方式和发布版本不一样。这一方面让构建需要加入额外动作，另一方面也不容易保证两套构建工程的一致性，难以确保开发人员每次发布软件前都通过了白盒测试。
2. 为了运行白盒测试，必须要搭建运行环境。有些执行机环境资源不太容易获得（比如嵌入式单板），这就给开发人员随时随地开展测试带来了障碍。
3. 当代码发生修改时，需要人为判断执行哪一部分白盒测试用例。当依赖关系复杂时，这种影响关系分析并不容易。
如果能够让代码在编译的时候，自动完成白盒测试，则上面 3 个问题将都不存在。当测试用例没有通过时，我们希望编译失败。这看起来像是天方夜谭，但随着 C++语言的编译期计算功能越来越成熟，对于相当一部分代码来说它已不再是幻想。
一个简单的例子
C++11 开始提供了强大的编译期计算工具：constexpr。在后续的 C++14/17/20 等版本中，constexpr 的功能被不断的扩展，被称为“病毒式扩张”的 C++特性[1]。这里先看一个获取字符串长度的 constexpr 函数（本文中代码都在 C++17 环境下编译运行）：
template<typename T, auto E = '\0'>constexpr size_t StrLen(const T& str) noexcept{ size_ti = 0; while (str[i] != E) { ++i; } return i;}复制代码
复制代码
这个函数和 C 库函数 strlen 的主要区别有两点：一是它泛化了 char 类型为模板参数；二是它可以在编译期计算。要注意的是，constexpr 函数也可以在运行期作为正常函数调用。
想要测试 StrLen，最直接的办法是用 constexpr 常量和 static_assert：
constexpr const char* g_str = "abc";static_assert(StrLen(g_str) == 3);复制代码
复制代码
这样当然行得通，但是这会污染全局名字空间，而且如果函数功能是对入参做修改（不要惊讶，constexpr 函数真的可以修改入参，而且是在编译期），传入 constexpr 类型的入参是行不通的。所以好一点的做法是写成测试函数：
constexpr bool TestStrLen() noexcept{ char testStr[] = "abc"; // 并不需要为constexpr assert(StrLen(testStr) ==3); // 不能用static_assert testStr[2]= '\0'; assert(StrLen(testStr) ==2); return true;}// 为了强制TestStrLen在编译期执行，必须有这行constexprbool DUMB = TestStrLen();复制代码
复制代码
注意在测试代码中，不需要传给被测函数 constexpr 入参，只要整个过程可以在编译期计算就行了。因此 TestStrLen 里面可以修改局部变量并检查结果。另外由于 StrLen 返回的结果并不是 constexpr 常量，因此检查输出时也不能用 static_assert。C++17 保证了当 assert 中的条件为 true 时，它可以在编译期执行[2]，所以 assert 调用不会影响编译期计算。
编译期测试的好处
除了本文开头所说的 3 个问题外，编译期测试还有其他的好处。比如，我们修改一下刚才的测试代码：
constexprbool TestStrLen() noexcept{ char testStr[] = {'a', 'b','c'}; // 少了结束符 assert(StrLen(testStr) ==3); // 内部数组越界 return true;}
constexprbool DUMB = TestStrLen();复制代码
复制代码
这段代码编译时，会产生以下错误：
D:\Work\Source_Codes\MyProgram\VSCode\main.cpp:45:33: in 'constexpr' expansion of 'TestStrLen()'D:\Work\Source_Codes\MyProgram\VSCode\main.cpp:41:5: in 'constexpr' expansion of 'StrLen<char[3]>(((const char (&)[3])(& testStr)))'D:\Work\Source_Codes\MyProgram\VSCode\main.cpp:45:34:error: array subscript value '3'is outside the bounds of array type 'char [3]' constexprbool DUMB = TestStrLen(); ^复制代码
复制代码
可以看到，如果白盒测试触发了数组越界，将会使编译报错。我们再来尝试一个空指针：
constexprbool TestStrLen() noexcept{ char* testStr = nullptr; assert(StrLen(testStr) ==0); return true;}
constexprbool DUMB = TestStrLen();复制代码
复制代码
这时编译器会报错：
D:\Work\Source_Codes\MyProgram\VSCode\main.cpp:45:33: in 'constexpr' expansion of 'TestStrLen()'D:\Work\Source_Codes\MyProgram\VSCode\main.cpp:41:5: in 'constexpr' expansion of 'StrLen<char*>(((char* const&)(& testStr)))'D:\Work\Source_Codes\MyProgram\VSCode\main.cpp:45:34:error: dereferencing a null pointer constexprbool DUMB = TestStrLen(); ^复制代码
复制代码
可以看到，编译期测试能有效的发现数组越界、空指针等问题**。**这是因为编译期计算并没有将代码翻译成机器指令运行，而是由编译器根据 C++标准推导表达式结果。任何的未定义行为都会导致编译错误。
如果使用通常的测试方法，则需要使用一些编译手段或者消毒器等技术来探测这些未定义行为，还不一定能保证探测到。而且相关问题定位起来也会困难得多。
需要注意的是，编译期测试并不是形式化验证，测试通过并不表示未定义行为一定不存在。只有用例设计的输入组合能够触发未定义行为时，才会产生编译错误。
编译期测试框架
上面的测试代码有个易用性问题：当 assert 失败导致测试不通过时，错误信息不太友好：
In file included from D:/mingw64/lib/gcc/x86_64-w64-mingw32/8.1.0/include/c++/cassert:44, from D:\Work\Source_Codes\MyProgram\VSCode\main.cpp:19:D:\Work\Source_Codes\MyProgram\VSCode\main.cpp:45:33: in 'constexpr' expansion of 'TestStrLen()'D:\Work\Source_Codes\MyProgram\VSCode\main.cpp:41:5:error: call to non-'constexpr' function 'void _assert(const char*, const char*,unsigned int)' assert(StrLen(testStr) == 2); ^~~~~~复制代码
复制代码
这个错误信息能看得人一头雾水。其原因是 assert 在条件为 false 时，将变身为非 constexpr 函数，导致编译器认为不满足 constexpr 求值条件。
这当然不是我们想要的。我们希望测试失败时要提示具体的用例，最好能具体到哪一行校验失败。
想要达成这个效果，需要一些技巧。一般的 C++编译器会在类模板的错误信息中打印出模板参数。利用这个特点，我们可以把测试失败的行号作为类模板参数，并强制该模板实例化。
#define ASSERT_RETURN(exp) \ if (!(exp)) { \ return __LINE__; \ }constexpruint32_t TestStrLen() noexcept{ const char* testStr = "abc"; ASSERT_RETURN(StrLen(testStr) ==2); // 失败时返回行号 return 0;}
template<std::uint32_t L>class TestFailedAtLine { static_assert(L == 0);}; // 模板显式实例化，强制运行测试用例函数template class TestFailedAtLine<TestStrLen()>;复制代码
复制代码
当 ASSERT_RETURN 校验失败时，编译提示信息会是这样：
D:\Work\Source_Codes\MyProgram\VSCode\main.cpp:In instantiation of 'class TestFailedAtLine<46>':D:\Work\Source_Codes\MyProgram\VSCode\main.cpp:56:16: required from hereD:\Work\Source_Codes\MyProgram\VSCode\main.cpp:52:21:error: static assertion failed static_assert(L == 0); ~~^~~~复制代码
复制代码
这里 TestFailedAtLine<46>告诉了我们第 46 行的 ASSERT_RETURN 失败了。这样定位问题就方便多了。
但如果测试用例有很多个，希望分多个函数写，还是有些麻烦——因为必须给每个函数配一个模板类（TestFailedAtLine）。如果加用例的时候忘记了写这个模板类，就会导致用例不会被执行。
一个易用的框架，应该尽可能做到让用户添加功能时只改一个地方。想要做到这点并不容易，因为 constexpr 函数必须要完整定义以后才能被调用。但是利用 lambda 可以达到效果，其原理是：设计一个函数接受多个 lambda 对象，并且依次执行这些 lambda 对象。每一个 lambda 对象都作为一个测试用例。
/ 仅用于中止递归
constexpruint32_t TestExcute() noexcept
{
return 0;
}
// 执行用例的函数，每一个参数都是待执行的测试用例
template<typename T, typename... F>
constexpruint32_t TestExcute(T func, F... funcs) noexcept
{
auto ret = func();
if (ret != 0) {
return ret;
}
return TestExcute(funcs...);
}
#define ASSERT_RETURN(exp) \
if (!(exp)) { \
return __LINE__; \
}
// 上面的代码可以放到公共头文件中，被测试用例cpp文件包含
// 下面的代码可放到测试cpp文件中，在链接时可以跳过该cpp
// 测试用例集，每个用例都是一个lambda对象
constexprstd::uint32_t FAILED_LINE =TestExcute(
// 常规测试
[]() -> std::uint32_t {
const char* testStr = "abc";
ASSERT_RETURN(StrLen(testStr) ==3);
return 0;
},
// 边界测试，输入空字符串
[]() -> std::uint32_t {
ASSERT_RETURN(StrLen("") == 0);
return 0;
},
// 扩展测试，元素为uint16_t类型，以0xFFFF结束
[]() -> std::uint32_t {
array<uint16_t, 4> a{10, 20, 30, 0xFFFF};
ASSERT_RETURN((StrLen<decltype(a), 0xFFFF>(a) == 3));
return 0;
}
// 还可以加入更多测试用例……
);
template<std::uint32_t L>
class TestFailedAtLine {
static_assert(L == 0);
};
// 模板显式实例化，强制运行测试用例函数
template class TestFailedAtLine<FAILED_LINE>;复制代码
复制代码
在这个测试框架中，想添加或者删除测试用例，只要在 TestExcute 函数调用里增删 lambda 函数就可以了，其他的地方都不用改。每个新增的测试用例（lambda 对象）都会确保被执行到。
测试框架利用了 lambda 对象的两个特性：构造函数和 operator()成员函数可以隐式的作为 constexpr 函数。前者确保 lambda 对象可以作为 constexpr 入参传给 TestExcute，后者确保编译期可以调用 lambda 对象。这两个特性需要 C++17 才能完整支持。
如注释所述，TestExcute 和其后的代码可以单独放到一个 cpp 文件中，并且不参与链接。但是该文件编译失败时，仍然会中止构建过程，达到测试防护效果。其实即使把所有代码都放到发布版本软件里去也没有问题，TestFailedAtLine 类型定义不会占用二进制空间，而 constexpr 的函数和常量因为没有被使用也会被编译器优化掉。
我们的测试框架看起来有模有样了，下面来看一个更复杂些的例子。
更复杂的例子——切割字符串
下面的代码以空格为分隔符来切割传入的字符串，每次可获取一个单词。很多人喜欢把这种功能设计为传入 string 并返回 vector，但这在 C++中是非常低效的做法。本文的代码使用 string_view，不仅不会产生拷贝字符串和内存分配开销，还让代码功能可以在编译期进行测试。
class Splitter {
public:
explicit constexpr Splitter(string_view whole) noexcept : whole(whole) {}
constexpr string_view NextWord() noexcept
{
if (wordEnd == string_view::npos){
return "";
}
wordBegin =whole.find_first_not_of(' ', wordEnd);
if (wordBegin == string_view::npos){
return "";
}
wordEnd =whole.find(' ', wordBegin);
if (wordEnd == string_view::npos){
return whole.substr(wordBegin);
}
return whole.substr(wordBegin, wordEnd - wordBegin);
}
private:
string_view whole;
size_twordBegin{0};
size_twordEnd{0};
};复制代码
复制代码
需要说明的是，string_view 的拷贝代价很小（内部只保存指针），因此作为函数参数时没有必要传引用。另外 string_view 所代表的字符串不可被修改，因此也没有必要加 const。此外还要注意 string_view 的结尾并不一定有**'\0'结束符，因此它可以用于指向字符串中间的某一段内容，但是切勿将 data()**返回的指针当做 C 字符串使用。
对代码写编译期测试用例如下：
/ 下面的代码可放到测试cpp文件中，在链接时可以跳过该cpp
// 测试用例集，每个用例都是一个lambda对象
constexprstd::uint32_t FAILED_LINE =TestExcute(
// 边界条件，空字符串
[]() -> std::uint32_t {
Splitter words("");
ASSERT_RETURN(words.NextWord() == ""sv);
return 0;
},
// 边界条件，只有空格
[]() -> std::uint32_t {
Splitter words(" ");
ASSERT_RETURN(words.NextWord() == ""sv);
return 0;
},
// 只有一个单词
[]() -> std::uint32_t {
Splitter words("abc");
ASSERT_RETURN(words.NextWord() == "abc"sv);
ASSERT_RETURN(words.NextWord() == ""sv);
return 0;
},
// 多个单词，单空格分割
[]() -> std::uint32_t {
Splitter words("C++compile time computation");
ASSERT_RETURN(words.NextWord() == "C++"sv);
ASSERT_RETURN(words.NextWord() == "compile"sv);
ASSERT_RETURN(words.NextWord() == "time"sv);
ASSERT_RETURN(words.NextWord() == "computation"sv);
ASSERT_RETURN(words.NextWord() == ""sv);
return 0;
},
// 多个单词，含多个连续空格，且首尾有空格
[]() -> std::uint32_t {
Splitter words(" 0 598 3426 ");
ASSERT_RETURN(words.NextWord() == "0"sv);
ASSERT_RETURN(words.NextWord() == "598"sv);
ASSERT_RETURN(words.NextWord() == "3426"sv);
ASSERT_RETURN(words.NextWord() == ""sv);
return 0;
}
);复制代码
复制代码
可以看到，编译期的测试用例可以覆盖相当全面的场景，对于代码质量保障有很大的好处。
如果后续 Splitter 类的代码（或者其依赖的下层代码）修改了，在增量编译时，编译期会自动识别是否需要重新“测试”，确保不会放过修改引入的错误。
编译期测试的当前限制和应用前景
编译期测试的限制就是 C++编译期计算的限制，主要为只能对 constexpr 接口进行测试。在 C++17 中，仍然有很多库函数不支持 constexpr，如大多数泛型算法、需要动态分配内存的所有容器（如 std::vector、std::string）等等。这导致当前编译期计算只能用于很小部分的底层函数。
但是，随着 C++后续版本的到来，编译期计算的允许范围会越来越大。刚刚发布的 C++20 版本已经将大多数的泛型算法改为了 constexpr 函数，并且还允许 operator new、虚函数、std::vector 和 std::string 在编译期计算[3]，这会使得相当大一部分的软件模块以后能够在编译期进行测试。
说不定，未来 C++代码的测试方法会因此发生革命。
尾注
[1] 称为“病毒式扩张”是因为 constexpr 函数要求其调用其他的函数也都是 constexpr 函数。因此当越来越多的底层函数定义为 constexpr 时，上层函数也越来越多的被标记为 constexpr。这个过程在标准库的代码中正在快速的进行。
[2] en.cppreference.com/w/cpp/error…
[3] 在这个页面中可以看到当前各编译器对 C++20 的支持进展。GCC 的最新版本已经能支持虚函数、泛型算法在编译期的计算了。可惜的是目前还没有编译器支持 std::vector 和 std::string 的编译期计算。
本文分享自华为云社区《让 C++代码在编译时完成白盒测试》，原文作者：飞得乐 。
点击关注，第一时间了解华为云新鲜技术~
评论