C语言中如何测试不透明类型的内部实现？

在测试C语言中的不透明指针类型时，目前了解到三种可行方法：

• 在测试源文件中直接包含定义该类型及相关操作函数的源文件（这是最简单的方法，但常被无理由反对）
• 提供条件可用的公共访问器：仅在包含头文件前定义LIB_TEST时，访问器才会生效
• 单独创建一个包含公共访问器的lib-test.h头文件

后两种方法不会将访问器纳入公共API（我们讨论的场景是：客户端无需了解不透明类型的内部实现，也不应获得任何访问器）。

请问在C语言中，常用的（或推荐的）做法是什么？哪种方法的优缺点更突出？

举个例子，假设存在如下结构体：

typedef struct arena {
    size_t count;
    size_t capacity;
    size_t current;
    size_t last_alloc_size;
    M_Pool *pools[];
} Arena;

以及关联函数：

void arena_reset(Arena *arena)
{
    for (size_t i = 0; i < arena->count; ++i) {
        arena->pools[i]->offset = 0;
    }
    arena->current = 1;
}

我希望断言arena_reset()确实将arena所有pools的offset字段设为0，并将arena的current字段设为1。但仅包含库提供的API头文件并无用处，因为该结构体仅提供了前向声明，无法访问其成员。

三种方法的优缺点分析与推荐 #

1. 直接包含源文件 #

• 优点：实现成本极低，无需额外编写测试相关代码，直接就能访问结构体内部成员，快速完成断言逻辑。
• 缺点：
  • 破坏封装性原则，测试代码直接依赖内部实现细节，一旦结构体成员或内部逻辑变更，测试代码必须同步修改，维护成本高。
  • 易引发编译依赖问题：源文件中的静态函数、全局变量等会被测试文件引入，容易出现符号冲突或重复定义的问题。
  • 模糊测试与生产代码的边界，不符合解耦的设计理念。

2. 条件编译的访问器 #

• 优点：
  • 不会污染公共API，只有定义了LIB_TEST的测试代码才能使用访问器，生产代码完全看不到这些接口。
  • 测试代码通过访问器获取数据，而非直接依赖内部实现，一定程度降低了耦合度。
  • 无需额外维护独立测试头文件，代码集中在公共头文件中，管理相对方便。
• 缺点：
  • 公共头文件中会混入测试相关的条件编译代码，增加了头文件复杂度，对生产代码的可读性有轻微影响。
  • 访问器的实现需要在库的源文件中添加条件编译块，增加了生产代码的冗余度。

3. 独立的lib-test.h测试头文件 #

• 优点：
  • 完全隔离测试与生产代码，公共API头文件和生产源文件中无任何测试相关内容，代码结构清晰。
  • 测试专属头文件可灵活定义各种测试所需的访问器、辅助函数，扩展性强。
  • 生产代码的编译完全不受测试代码影响，避免了条件编译带来的潜在问题。
• 缺点：
  • 需要额外维护独立的头文件，增加了项目文件数量，初期有一定的设置成本。
  • 访问器的实现需要单独处理（比如在库的源文件中通过条件编译或单独的测试源文件实现），需确保测试编译时能正确链接。

推荐做法 #

实际项目中，条件编译的访问器和独立测试头文件都是常用的推荐方案，具体选择取决于项目规模和团队习惯：

• 若项目规模较小，希望尽量减少文件数量，条件编译的访问器是更高效的选择，兼顾封装性与测试便利性。
• 若项目规模较大，对代码模块化和可维护性要求较高，独立的lib-test.h是更优方案，能彻底隔离测试与生产代码，避免潜在耦合。

而直接包含源文件的方法，除非是临时快速测试，否则不推荐在正式项目中使用——它带来的维护成本和封装性破坏远大于其便利性。

内容的提问来源于stack exchange，提问作者Madagascar