# 28 | 尝试升级（上）：完善测试框架的功能与提示 你好，我是胡光，欢迎回来。 在上一节课中呢，我们学习了测试框架的主要功能流程，完成了最重要的 RUN\_ALL\_TESTS 函数的功能逻辑。并且在这个学习期间，我们还使用了注册函数的技巧，就是让一些函数先于主函数执行，将测试用例函数信息记录在一个函数指针数组中，为后续的 RUN\_ALL\_TESTS 函数功能的执行作铺垫。 可你有没有发现，我们上节课程所完成的代码，只能让我们的测试框架在整体流程功能上跑通，然而程序的输出内容却不如 gtest 丰富。 今天，我们的主要任务，就是参考 gtest 的输出，逐步完善我们自己测试框架的相关信息输出方面的细节，从而让输出内容更加符合我们想要的信息。来，让我们一起开始吧。 ## 温故知新，gtest 的输出结果 我们先来回顾一下 gtest 的输出结果，gtest 的输出内容大体可以分成三个部分。 第一部分，一套单元测试的相关信息： ``` [==========] Running 2 tests from 1 test suite. [----------] Global test environment set-up. [----------] 2 tests from test_is_prime ``` 这段信息说明这套单元测试中，包含了 2 个测试用例。 第二部分，是每个单元测试运行信息的输出： ``` [ RUN ] test_is_prime.test1 [ OK ] test_is_prime.test1 (1 ms) [ RUN ] test_is_prime.test2 gtest_test.cpp:25: Failure Expected equality of these values: is_prime(4) Which is: 1 0 gtest_test.cpp:26: Failure Expected equality of these values: is_prime(0) Which is: 1 0 gtest_test.cpp:27: Failure Expected equality of these values: is_prime(1) Which is: 1 0 [ FAILED ] test_is_prime.test2 (0 ms) ``` 如上所示，第一个单元测试 test\_is\_prime.test1 运行结果正确，所用时间是 1ms；第二个单元测试 test\_is\_prime.test2 中，有三个判等 EXPECT 断言的结果是错误的，也就是 is\_prime 函数的返回值，和测试用例中期望的返回值不符，这说明 is\_prime 函数存在 Bug。 第三部分，就是这套单元测试的总结信息，以及整个程序单元测试结果的汇总信息。这段信息，有兴趣的小伙伴可以自己理解着看一下，由于不是咱们今天课程的重点，就不展开介绍了。 ``` [----------] 2 tests from test_is_prime (1 ms total) [----------] Global test environment tear-down [==========] 2 tests from 1 test suite ran. (1 ms total) [ PASSED ] 1 test. [ FAILED ] 1 test, listed below: [ FAILED ] test_is_prime.test2 1 FAILED ``` 好了，关于gtest 的输出内容，我大致说清楚了。 今天呢，我们先忽略 gtest 输出内容的第一部分和第三部分，主要关注 gtest 输出内容的第二部分，也就是每个单元测试运行信息的输出部分。通过第二部分的输出内容，你能想出我们应该从哪些方面来完善测试框架？ 这里呢，我给出我的想法：通过观察第二部分的输出，我们基本要从三个方面完善测试框架的输出信息。 1. 在每个测试用例运行之前，要先行输出相关测试用例的名字； 2. 每个测试用例运行结束以后，要输出测试用例的运行时间与运行结果（OK 或者 FAILED）； 3. 若测试用例中的 EXPECT 断言出错，需要输出错误提示信息。 好了，优化的方向找到了，那么接下来，我们就开始测试框架改装行动吧！ ## 测试用例的名字输出 首先是如何输出测试用例的名字。我们先回忆一下上节课设计的注册函数，如下所示： ``` #define TEST(test_name, func_name) \ void test_name##_##func_name(); \ __attribute__((constructor)) \ void register_##test_name##_##func_name() { \ test_function_arr[test_function_cnt] = test_name##_##func_name; \ test_function_cnt++; \ } \ void test_name##_##func_name() ``` 注册函数是随着 TEST 展开的，从展开的代码逻辑中可以看到，它只是将测试用例的函数地址记录在了函数指针数组中。要想 RUN\_ALL\_TESTS 函数后续能够输出测试用例的函数名称的话，我们只需要修改注册函数的功能逻辑即可，也就是让注册函数在记录函数信息的时候，增加记录对应测试用例的名称。 而这个名称信息，应该记录在哪里呢？有两种代码实现方式： 1. 另外开辟一个记录测试用例名称的字符串数组； 2. 修改 test\_function\_arr 数组中的元素类型，将新增的测试用例名称以及函数地址信息打包成一个数据元素。 显然，相较于第一种实现方式，第二种代码实现方式会使程序具有更好的封装特性。我们采用之前在“语言基础篇“中学习的结构体相关知识，就可以完成这种多种数据类型打包成一种新的数据类型的功能需求。 下面就是我们将函数指针信息和测试用例名称信息，封装成的一个新的结构体类型： ``` struct test_function_info_t { test_function_t func; // 测试用例函数指针，指向测试用例函数 const char *name; // 指向测试用例名称 } test_function_arr[100]; int test_function_cnt = 0; ``` 如代码所示，我们定义了一种新的数据类型，叫做 test\_function\_info\_t。这种结构体类型包含了指向测试用例的函数指针 func 字段， 与指向测试用例名称的字符串指针 name 字段，并且我们将这种结构体类型，作为 test\_function\_arr 数组新的元素类型。 既然测试用例信息的存储区 test\_function\_arr 的数据类型发生了改变，那么负责存储信息的注册函数，与使用信息的 RUN\_ALL\_TESTS 函数的相关逻辑都需要作出改变。 首先，我们来看注册函数的改变。想要修改注册函数的逻辑，就是修改 TEST 宏，从功能上来说，注册函数中需要额外记录一个测试用例名称信息，示例代码如下： ``` #define TEST(test_name, func_name) \ void test_name##_##func_name(); \ __attribute__((constructor)) \ void register_##test_name##_##func_name() { \ test_function_arr[test_function_cnt].func = test_name##_##func_name; \ test_function_arr[test_function_cnt].name = #func_name "." #test_name; \ test_function_cnt++; \ } \ void test_name##_##func_name() ``` 代码中主要是增加了第 6 行的逻辑，这一行的代码将 TEST 宏参数的两部分，拼成一个字符串，中间用点 (.) 连接，例如 TEST(test1, test\_is\_prime) 宏调用中，拼凑的字符串就是 test\_is\_prime.test1，和 gtest 中的输出的测试用例名称信息格式是一致的。 改完了注册函数的逻辑以后，最后调整一下 RUN\_ALL\_TESTS 中使用 test\_function\_arr 数组的逻辑代码即可： ``` int RUN_ALL_TESTS() { for (int i = 0; i < test_function_cnt; i++) { printf("[ RUN ] %s\n", test_function_arr[i].name); test_function_arr[i].func(); printf("RUN TEST DONE\n\n"); } return 0; } ``` 代码中的第 3 行，是仿照 gtest 的输出格式进行调整的，在输出测试用例名称之前，先输出一段包含 RUN 英文的标志信息。 至此，我们就完成了输出测试用例名字的框架功能改造。 ## 输出测试用例的运行结果信息 接下来，就让我们进行第二个功能改造：输出测试用例的运行结果信息。 以下是我们示例代码中的 2 个测试用例，在 gtest 框架下的运行结果信息输出： ``` [ OK ] test_is_prime.test1 (1 ms) [ FAILED ] test_is_prime.test2 (0 ms) ``` 根据输出的信息，我们可知 gtest 会统计每个测试用例运行的时间，并以毫秒为计量单位，输出此时间信息。不仅如此，gtest 还会输出与测试用例是否正确相关的信息，如果测试用例运行正确，就会输出一行包含 OK 的标志信息，否则就输出一行包含 FAILED 的标志信息。 根据我们自己测试框架的设计，这行信息只有可能是在 RUN\_ALL\_TESTS 函数的 for 循环中，执行完每一个测试用例函数以后输出的信息。 由此，我们面临的是两个需要解决的问题： 1. 如何统计函数过程的运行时间？ 2. 如何确定获得每一个测试用例函数的测试结果是否正确？ 说到如何统计函数过程的运行时间，我这里就需要介绍两个新的知识点，一个是函数 clock() ，另 一个是宏 CLOCKS\_PER\_SEC。下面我会对它们详细讲解。 我们先说函数 clock() 。它的返回值代表了：从运行程序开始，到调用 clock() 函数时，经过的 CPU 时钟计时单元。并且，这个 clock() 函数的返回值，实际上反映的是我们程序的运行时间。那这个 CPU 时钟计时单元究竟是什么呢？你可以把 1 个 CPU 时钟计时单元，简单的理解成是一个单位时间长度，只不过这个单位时间长度，不是我们常说的 1 秒钟。 接下来，我们再说说宏 CLOCKS\_PER\_SEC 。它实际上是一个整型值，代表多少个 CPU 时钟计时单元是 1 秒。这个值在不同环境中会有所不同，在早年我的 Windows 电脑上，这个值是1000，也就是1000 个 CPU 时钟计时单位等于 1 秒。而现在我的 Mac 电脑上，这个值是 1000000，也就是 1000000 个 CPU 时钟计时单位等于 1 秒钟。显然，这个数字越大，统计粒度就越精细。 有了上面这两个工具，我们就可以轻松地统计一个函数的运行时间。在函数运行之前，记录一个 clock() 值，函数运行结束以后，再记录一个 clock() 值，用两个记录值的差值除以 CLOCKS\_PER\_SEC ，得到的就是以秒为单位的函数运行时间，再乘以 1000，即为毫秒单位。 这样呢，我们就解决了刚刚提的第一个问题：统计函数过程的运行时间。 至于如何获得每一个测试用例的测试结果，我们可以采用一个简单的解决办法，那就是记录一个全局变量，代表测试用例结果正确与否。当测试用例中的 EXPECT\_EQ 断言发生错误时，就修改这个全局变量的值，这样我们的 RUN\_ALL\_TESTS 函数，就可以在测试用例函数执行结束以后，得知执行过程是否有错。 综合以上所有信息，我们可以重新设计 RUN\_ALL\_TESTS 函数如下： ``` int test_run_flag; #define EXPECT_EQ(a, b) test_run_flag &= ((a) == (b)) int RUN_ALL_TESTS() { for (int i = 0; i < test_function_cnt; i++) { printf("[ RUN ] %s\n", test_function_arr[i].name); test_run_flag = 1; long long t1 = clock(); test_function_arr[i].func(); long long t2 = clock(); if (test_run_flag) { printf("[ OK ] "); } else { printf("[ FAILED ] "); } printf("%s", test_function_arr[i].name); printf(" (%.0lf ms)\n\n", 1.0 * (t2 - t1) / CLOCKS_PER_SEC * 1000); } return 0; } ``` 代码中的第 8 行是在测试用例运行之前，记录一个开始时间值 t1；代码中的第 10 行是在测试用例函数执行完后，记录一个结束时间值 t2；在代码的第 17 行，根据 t1 、t2 以及 CLOCKS\_PER\_SEC 的值，计算得到测试用例函数实际运行的时间，并输出得到的结果。 这段代码中增加了一个全局变量“test\_run\_flag”，这个变量每次在测试用例执行之前，都会被初始化为 1，当测试用例结束执行以后，RUN\_ALL\_TESTS 函数中，根据 test\_run\_flag 变量的值，选择输出 OK 或者 FAILED 的标志信息。同时，我们可以看到，test\_run\_flag 变量的值只有在 EXPECT\_EQ 断言中，才可能被修改。 ## EXPECT\_EQ 断言的实现 最后呢，我们还剩下一个 EXPECT\_EQ 断言的实现，这个就给你留作思考题，请你基于我上述所讲的内容，试试自己实现这个带错误提示输出的 EXPECT\_EQ 断言吧。也欢迎你把你的答案写在留言区，我们一起讨论。 ## 课程小结 通过今天的课程呢，我希望你认识到**工程开发中的一个基本原则：功能迭代，数据先行。也就是说，无论我们做什么样的功能开发，首先要考虑的是与数据相关的部分。**更细致的解释，就是你考虑某种功能的实现，要明白这个功能都依赖于哪些数据信息，这些信息在哪里存储，在哪里修改，在哪里读取使用。把数据相关部分设计明白了，你的功能开发也就基本实现了一半了。 就像我们今天改造的第一个功能，输出测试用例的名字。 首先，我们考虑如何存储名字信息，最先被修改的就是 test\_function\_arr 数组的数据类型，我们改造了数据存储的结构。然后，我们修改了注册函数的相关功能逻辑，也就是解决了数据的写入与修改过程。最后，我们修改 RUN\_ALL\_TESTS 中的输出逻辑，也就是解决了数据在哪里读取和使用的事情。 至此，我已经向你演示了基本的功能迭代开发过程。接下来你可以自己试着，给输出的内容加上点儿颜色，以便更清晰地展示测试过程中的测试信息。除此之外呢，你也可以开动你的创造力，给测试框架加些令人惊喜的功能。 好了，今天就到这里了，我是胡光，我们下节课见。