4、CUnit高级用法：测试夹具、参数化测试、套件组织与报告生成

好，咱们继续往下走。前面几章我们把CUnit的基本用法过了一遍，你大概已经能写出简单的单元测试了。但说实话，真实项目里的代码没那么乖——有全局变量要初始化、有资源要申请释放、有几十上百个测试用例要管理。这时候，CUnit的高级功能就该上场了。

我个人习惯把这一章叫做「从能用到好用」的跨越。你想想看，如果每个测试用例都要手动去初始化一遍硬件寄存器、手动去malloc内存再free，那写测试的时间比写业务代码还长，谁受得了？

4.1 测试夹具：Setup和Teardown

测试夹具（Fixture）这个概念，说白了就是「测试前后的固定动作」。Setup函数在每个测试用例执行前自动调用，Teardown则在每个测试用例执行后自动调用。我在项目中遇到过最典型的场景：测试一个环形缓冲区模块，每个用例开始前都要把缓冲区清空、把读写指针归零。如果每个用例里都写一遍，代码冗余不说，还容易漏掉。

CUnit里注册夹具的方式很简单，看代码：

#include <CUnit/CUnit.h>
#include <CUnit/Basic.h>

static int* shared_buffer = NULL;

// Setup函数：每个测试用例前执行
int setup_buffer(void) {
    shared_buffer = (int*)malloc(1024 * sizeof(int));
    if (shared_buffer == NULL) return -1;  // 返回-1表示失败
    memset(shared_buffer, 0, 1024 * sizeof(int));
    return 0;  // 返回0表示成功
}

// Teardown函数：每个测试用例后执行
int teardown_buffer(void) {
    free(shared_buffer);
    shared_buffer = NULL;
    return 0;
}

// 测试用例1
void test_write(void) {
    shared_buffer[0] = 42;
    CU_ASSERT_EQUAL(shared_buffer[0], 42);
}

// 测试用例2
void test_read(void) {
    CU_ASSERT_EQUAL(shared_buffer[0], 0);  // 因为每个用例前都清空了
}

void register_tests(void) {
    CU_pSuite suite = CU_add_suite("BufferSuite", setup_buffer, teardown_buffer);
    CU_add_test(suite, "test write", test_write);
    CU_add_test(suite, "test read", test_read);
}

注意：Setup和Teardown函数的返回值很关键。返回0表示成功，返回-1表示失败。如果Setup返回-1，CUnit会跳过该套件下的所有测试用例。我曾经调试一个bug调了半天，最后发现是Setup里文件打开失败返回了-1，整个套件静默跳过了——嗯，这个坑我替你们踩过了。

小技巧：如果多个测试套件需要不同的初始化逻辑，可以给每个套件注册不同的Setup/Teardown。CUnit支持每个套件独立配置，互不干扰。

4.2 参数化测试：用数据驱动用例

参数化测试，说白了就是「同一个测试逻辑，换不同的输入数据跑多遍」。比如测试一个绝对值函数abs()，你总得试正数、负数、零、边界值吧？如果每个值写一个测试函数，那代码量就爆炸了。

CUnit本身没有内置的参数化测试机制，但我们可以用C语言的老办法——循环+数组。我习惯这样写：

typedef struct {
    int input;
    int expected;
} TestCase;

static TestCase test_data[] = {
    {5, 5},
    {-3, 3},
    {0, 0},
    {2147483647, 2147483647},
    {-2147483647, 2147483647}  // 注意：-2147483648会溢出，这是另一个话题
};

void test_abs_param(void) {
    for (int i = 0; i < sizeof(test_data)/sizeof(test_data[0]); i++) {
        int result = my_abs(test_data[i].input);
        CU_ASSERT_EQUAL(result, test_data[i].expected);
        if (result != test_data[i].expected) {
            // 失败时打印具体数据，方便定位
            printf("Failed: input=%d, expected=%d, got=%d\n",
                   test_data[i].input, test_data[i].expected);
        }
    }
}

为什么我不直接用CU_ASSERT_EQUAL然后不管了？因为如果第3个数据失败了，你只知道「有个用例失败了」，但不知道是哪个输入导致的。加上打印信息，调试效率高很多。这是我在实际项目中吃了亏才养成的习惯。

核心思路：参数化测试的本质是「数据与逻辑分离」。测试逻辑只写一遍，数据放在表格里。这样新增测试用例只需要加一行数据，不需要动代码。

4.3 测试套件的组织与管理

项目大了以后，测试用例可能成百上千。怎么组织？我的经验是：按模块分套件，按功能分用例。

举个例子，一个通信协议栈可能有这些模块：

  • Buffer模块：环形缓冲区、动态缓冲区
  • Frame模块：帧封装、帧解析
  • CRC模块：校验计算、校验验证
  • Session模块：会话管理、超时处理

每个模块对应一个测试套件（Suite），每个函数或功能点对应一个测试用例（Test）。CUnit支持嵌套注册，但实际项目中我建议扁平化管理——一个.c文件对应一个套件，清晰明了。

// test_buffer.c
CU_pSuite buffer_suite = CU_add_suite("BufferSuite", init_buffer, cleanup_buffer);
CU_add_test(buffer_suite, "test_create", test_buffer_create);
CU_add_test(buffer_suite, "test_write", test_buffer_write);
CU_add_test(buffer_suite, "test_read", test_buffer_read);

// test_frame.c
CU_pSuite frame_suite = CU_add_suite("FrameSuite", init_frame, cleanup_frame);
CU_add_test(frame_suite, "test_pack", test_frame_pack);
CU_add_test(frame_suite, "test_unpack", test_frame_unpack);

// test_crc.c
CU_pSuite crc_suite = CU_add_suite("CRCSuite", NULL, NULL);  // 不需要夹具
CU_add_test(crc_suite, "test_crc8", test_crc8);
CU_add_test(crc_suite, "test_crc16", test_crc16);

然后在主函数里统一注册：

int main(void) {
    CU_initialize_registry();
    
    // 注册所有套件
    register_buffer_suite();
    register_frame_suite();
    register_crc_suite();
    
    CU_basic_run_tests();
    CU_cleanup_registry();
    return 0;
}

组织原则：每个测试文件只做一件事。test_buffer.c只测缓冲区，test_frame.c只测帧处理。这样当某个模块的测试挂了，你一眼就知道问题出在哪，不用翻遍整个项目。

4.4 测试报告的生成

测试跑完了，结果怎么看？CUnit提供了几种输出模式：

模式 函数 特点
Basic CU_basic_run_tests() 控制台输出，简单直接
Console CU_console_run_tests() 交互式，可以选套件跑
Automated CU_automated_run_tests() 生成XML文件，适合CI集成

我个人最常用的是Automated模式。为什么？因为它生成的是结构化的XML，可以交给Jenkins、GitLab CI这些工具去解析，自动生成趋势图、失败率统计。你想想看，每次提交代码后，CI自动跑一遍测试，然后给你发一封邮件：「本次测试通过率98.5%，新增3个失败用例」——这感觉多好。

Automated模式的使用也很简单：

int main(void) {
    CU_initialize_registry();
    
    // 注册测试套件...
    
    // 设置输出文件前缀
    CU_set_output_filename("TestReport");
    // 运行并生成XML
    CU_automated_run_tests();
    
    CU_cleanup_registry();
    return 0;
}

运行后会生成两个文件：TestReport-Result.xml（测试结果）和TestReport-Listing.xml（测试列表）。前者包含每个用例的通过/失败状态、耗时等信息，后者包含套件和用例的层次结构。

避坑指南：Automated模式生成的XML文件默认放在当前工作目录。如果你的CI系统在临时目录里跑测试，记得把输出路径设置成固定的artifacts目录，否则报告会被清理掉。我曾经因为这个原因，连续三天没看到测试报告，还以为是CI坏了——结果只是路径没配对。

4.5 实战经验总结

好了，这一章的内容差不多就这些。最后分享几个我这些年积累下来的小经验：

  • 夹具要轻量：Setup里别做太重的操作，比如打开数据库连接、启动网络服务。这些应该放在套件级别的初始化里，而不是每个用例都做一次。
  • 参数化测试的数据要覆盖边界：别只测正常值。空指针、0长度、最大值、最小值——这些边界条件最容易出bug。
  • 套件命名要有规律：我习惯用「模块名_Suite」的格式，比如Buffer_Suite、CRC_Suite。这样在CI报告里一眼就能看出是哪个模块出了问题。
  • 报告要保留历史：Automated模式生成的XML建议保留至少30天的历史。这样你可以对比「昨天测试通过了，今天怎么挂了」，快速定位引入问题的提交。

下一章我们会聊CUnit的进阶话题——模拟（Mock）和桩（Stub）的使用。这是嵌入式单元测试里最硬核的部分，也是真正能帮你测出深层bug的利器。到时候见。

← 上一章 📖 返回目录 下一章 →