摘要：如果能够让代码在编译的时候，自动完成白盒测试，这不是天方夜谭。
白盒测试也叫开发者测试，是对特定代码函数或模块所进行的功能测试。当前主流的白盒测试方法是：先针对仿真或者生产环境编译出可执行文件，然后运行得到测试结果。这种方法有3个问题：
- 可能需要专门针对白盒测试额外做一次构建。这是因为仿真环境和实际运行环境可能是不同的硬件平台，而且白盒测试需要额外链接一些库（比如GTest），构建方式和发布版本不一样。这一方面让构建需要加入额外动作，另一方面也不容易保证两套构建工程的一致性，难以确保开发人员每次发布软件前都通过了白盒测试。
- 为了运行白盒测试，必须要搭建运行环境。有些执行机环境资源不太容易获得（比如嵌入式单板），这就给开发人员随时随地开展测试带来了障碍。
- 当代码发生修改时，需要人为判断执行哪一部分白盒测试用例。当依赖关系复杂时，这种影响关系分析并不容易。
如果能够让代码在编译的时候，自动完成白盒测试，则上面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_t i = 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在编译期执行，必须有这行
constexpr bool DUMB = TestStrLen();
注意在测试代码中，不需要传给被测函数constexpr入参，只要整个过程可以在编译期计算就行了。因此TestStrLen里面可以修改局部变量并检查结果。另外由于StrLen返回的结果并不是constexpr常量，因此检查输出时也不能用static_assert。C++17保证了当assert中的条件为true时，它可以在编译期执行[2]，所以assert调用不会影响编译期计算。
编译期测试的好处
除了本文开头所说的3个问题外，编译期测试还有其他的好处。比如，我们修改一下刚才的测试代码：
constexpr bool TestStrLen() noexcept
{
char testStr[] = {'a', 'b', 'c'}; // 少了结束符
assert(StrLen(testStr) == 3); // 内部数组越界
return true;
}
constexpr bool 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]'
constexpr bool DUMB = TestStrLen();
^
可以看到，如果白盒测试触发了数组越界，将会使编译报错。我们再来尝试一个空指针：
constexpr bool TestStrLen() noexcept
{
char* testStr = nullptr;
assert(StrLen(testStr) == 0);
return true;
}
constexpr bool 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
constexpr bool 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__; \
}
constexpr uint32_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 here
D:\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对象都作为一个测试用例。
// 仅用于中止递归
constexpr uint32_t TestExcute() noexcept
{
return 0;
}
// 执行用例的函数，每一个参数都是待执行的测试用例
template<typename T, typename... F>
constexpr uint32_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对象
constexpr std::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<string>，但这在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_t wordBegin{0};
size_t wordEnd{0};
};
需要说明的是，string_view的拷贝代价很小（内部只保存指针），因此作为函数参数时没有必要传引用。另外string_view所代表的字符串不可被修改，因此也没有必要加const。此外还要注意string_view的结尾并不一定有'\0'结束符，因此它可以用于指向字符串中间的某一段内容，但是切勿将data()返回的指针当做C字符串使用。
对代码写编译期测试用例如下：
// 下面的代码可放到测试cpp文件中，在链接时可以跳过该cpp
// 测试用例集，每个用例都是一个lambda对象
constexpr std::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] https://en.cppreference.com/w/cpp/error/assert
[3] 在这个页面中可以看到当前各编译器对C++20的支持进展。GCC的最新版本已经能支持虚函数、泛型算法在编译期的计算了。可惜的是目前还没有编译器支持std::vector和std::string的编译期计算。
本文分享自华为云社区《让C++代码在编译时完成白盒测试》，原文作者：飞得乐 。
点击关注，第一时间了解华为云新鲜技术~
