8、参数化测试：如何用循环或宏实现多组输入数据的测试、避免重复代码

写单元测试最怕什么？我个人最怕的就是重复。你想想看，测试一个函数，输入不同参数，逻辑一模一样，就是数据不同。如果每个用例都写一个TEST()，那代码量直接翻倍，维护起来也头疼。

我在项目中遇到过这样一个场景：一个校验函数，需要测试边界值、正常值、异常值，足足有20多组数据。如果每组都单独写一个测试用例，那文件得有上千行。后来我用参数化测试，把数据塞进一个数组，循环跑一遍，代码瞬间缩到几十行。嗯，这才是测试该有的样子。

8.1 为什么需要参数化测试？

说白了，参数化测试就是「一份测试逻辑，多组输入数据」。它的核心价值在于：

  • 消除重复代码：同样的断言逻辑，不用写N遍
  • 提高覆盖率：加一组数据就是加一个用例，成本极低
  • 便于维护：改逻辑只改一处，加数据只加一行

核心思想：把「测试逻辑」和「测试数据」分离。逻辑写一次，数据用数组或宏定义集中管理。

8.2 用循环实现参数化测试

这是最直接的方式。把测试数据放在一个结构体数组里，然后用for循环遍历执行。我习惯用这种方式处理中等规模的数据集（10~50组）。

// 被测函数：计算两个数的最大公约数
int gcd(int a, int b) {
    while (b != 0) {
        int temp = b;
        b = a % b;
        a = temp;
    }
    return a;
}

// 参数化测试
typedef struct {
    int a;
    int b;
    int expected;
} TestCase;

static TestCase test_cases[] = {
    {12, 8, 4},
    {100, 25, 25},
    {7, 13, 1},
    {0, 5, 5},
    {18, 0, 18},
    {54, 24, 6},
    {1, 1, 1},
    {999, 333, 333}
};

static int test_count = sizeof(test_cases) / sizeof(test_cases[0]);

void test_gcd_parameterized(void) {
    for (int i = 0; i < test_count; i++) {
        int result = gcd(test_cases[i].a, test_cases[i].b);
        // 这里用自定义断言，或者框架的断言宏
        ASSERT_EQ_INT(result, test_cases[i].expected);
    }
}

小技巧：我建议在循环里加上一个计数器，如果某组数据失败，能直接定位到是哪一组。比如：printf("Failed at case %d: a=%d, b=%d\n", i, test_cases[i].a, test_cases[i].b);

8.3 用宏实现参数化测试

宏的方式更灵活，适合测试框架不支持参数化，或者你想让测试用例看起来更「独立」的场景。我曾经在嵌入式项目中，因为测试框架太轻量，没有参数化支持，就用宏自己造了一个。

// 定义一个参数化测试宏
#define PARAM_TEST(name, func, data_array, count) \
    void test_##name(void) { \
        for (int i = 0; i < (count); i++) { \
            int result = func(data_array[i].input); \
            ASSERT_EQ_INT(result, data_array[i].expected); \
        } \
    }

// 使用示例：测试绝对值函数
typedef struct {
    int input;
    int expected;
} AbsTestCase;

static AbsTestCase abs_cases[] = {
    {5, 5},
    {-5, 5},
    {0, 0},
    {2147483647, 2147483647},
    {-2147483647, 2147483647}  // 注意：INT_MIN 会溢出，单独处理
};

PARAM_TEST(abs_func, my_abs, abs_cases, 5)

避坑指南：我曾经在宏里直接写死数组长度，结果后来加数据忘了改宏参数，导致漏测。所以建议用 sizeof(array)/sizeof(array[0]) 自动计算长度，或者显式传入 count 参数。

8.4 结合测试框架的参数化特性

如果你用的是主流测试框架（如 Unity、CUnit、Google Test 的 C 语言变体），它们通常有内置的参数化支持。以 Unity 为例，我常用这种方式：

// Unity 框架 + 参数化
void test_gcd_with_params(void) {
    int a[] = {12, 100, 7, 0, 18, 54, 1, 999};
    int b[] = {8, 25, 13, 5, 0, 24, 1, 333};
    int exp[] = {4, 25, 1, 5, 18, 6, 1, 333};
    
    for (int i = 0; i < 8; i++) {
        int result = gcd(a[i], b[i]);
        TEST_ASSERT_EQUAL_INT(exp[i], result);
    }
}

嗯，这里要注意：Unity 的 TEST_ASSERT_EQUAL_INT 会在失败时打印行号，但不会告诉你具体是哪组数据。所以我习惯在循环里加个 TEST_MESSAGE 或者自己封装一个带索引的断言宏。

8.5 参数化测试的进阶技巧

在实际项目中，我总结了几条经验：

  • 数据驱动：把测试数据放在独立的 .h 文件或 .c 文件中，用 extern 引用。这样改数据不用动测试逻辑。
  • 边界值优先：参数化测试特别适合边界值分析。比如测试一个范围检查函数，把最小值、最大值、临界值都塞进去。
  • 组合爆炸处理：如果函数有多个参数，不要穷举所有组合。用正交表或等价类划分，选有代表性的组合。

我的习惯：对于嵌入式底层驱动测试，我通常把寄存器配置值、预期返回值、错误码都放在一个结构体里，然后用循环跑。这样一次测试能覆盖几十种配置组合，效率极高。

8.6 知识体系：参数化测试的核心逻辑

下面这张图是我自己总结的参数化测试流程，你看一眼就明白了：

参数化测试核心逻辑 测试数据数组 for 循环 / 宏展开 调用被测函数 + 断言 通过 / 失败（定位索引） 数据与逻辑分离 一次编写，多次执行 自动遍历所有数据 快速定位失败用例

8.7 常见问题与避坑

问题 原因 解决方案
循环中某个用例失败，后续用例不执行 断言宏直接 return 或 abort 用非致命断言（如 Unity 的 TEST_ASSERT_EQUAL_INT 不会 abort），或者自己封装一个记录错误但不中断的版本
宏展开后代码膨胀 宏里包含大量重复代码 把公共逻辑提取成函数，宏只做数据传递和循环控制
数组太大，栈溢出 测试数据定义在函数内部 用 static 修饰数组，或者定义在全局区
调试时不知道哪组数据失败 没有打印索引信息 在断言前加 printf 或日志，输出当前索引和输入值

个人经验：我一般会在测试数据数组里加一个「用例名称」字段，比如 const char* name。这样失败时直接打印名称，比索引号直观多了。尤其是团队协作时，别人一看就知道是哪个场景出了问题。

8.8 总结

参数化测试不是什么高深的技术，说白了就是「用循环代替复制粘贴」。但就是这个小技巧，能让你的测试代码从臃肿变得清爽。我个人强烈建议：只要测试数据超过3组，就用参数化。别犹豫，省下来的时间都是你的。

记住：好的测试代码，不是写得多，而是写得巧。参数化测试就是那个「巧」字。

公众号:蓝海资料掘金营，微信deep3321

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