鱼和熊掌兼得:C++代码在编译时完成白盒测试

摘要:如果能够让代码在编译的时候,自动完成白盒测试,这不是天方夜谭。

白盒测试也叫开发者测试,是对特定代码函数或模块所进行的功能测试。当前主流的白盒测试方法是:先针对仿真或者生产环境编译出可执行文件,然后运行得到测试结果。这种方法有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_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::vectorstd::string)等等。这导致当前编译期计算只能用于很小部分的底层函数。

但是,随着C++后续版本的到来,编译期计算的允许范围会越来越大。刚刚发布的C++20版本已经将大多数的泛型算法改为了constexpr函数,并且还允许operator new、虚函数、std::vectorstd::string在编译期计算[3],这会使得相当大一部分的软件模块以后能够在编译期进行测试。

说不定,未来C++代码的测试方法会因此发生革命。

尾注

[1] 称为“病毒式扩张”是因为constexpr函数要求其调用其他的函数也都是constexpr函数。因此当越来越多的底层函数定义为constexpr时,上层函数也越来越多的被标记为constexpr。这个过程在标准库的代码中正在快速的进行。

[2] https://en.cppreference.com/w/cpp/error/assert

[3] 在这个页面中可以看到当前各编译器对C++20的支持进展。GCC的最新版本已经能支持虚函数、泛型算法在编译期的计算了。可惜的是目前还没有编译器支持std::vectorstd::string的编译期计算。

本文分享自华为云社区《让C++代码在编译时完成白盒测试》,原文作者:飞得乐 。

 

点击关注,第一时间了解华为云新鲜技术~

已标记关键词 清除标记