第四章 桩函数实现技术：四种核心方法

桩函数怎么写？这是很多嵌入式工程师刚接触集成测试时的第一反应。我当年也踩过不少坑，最开始只会用最笨的办法——改源码。后来慢慢摸索出四种主流技术，今天一次性讲透。

这四种技术分别是：函数指针桩、条件编译桩、链接替换桩和宏定义桩。它们各有各的适用场景，也各有各的坑。咱们一个一个来。

4.1 函数指针桩：最灵活的运行时替换

函数指针桩的核心思想很简单——把被调函数做成可配置的。你定义一个函数指针变量，测试时指向桩函数，正式运行时指向真实函数。

我在一个车载通信协议栈项目里用过这招。当时要模拟CAN总线故障，真实驱动没法在PC上跑。用函数指针桩，测试代码里一键切换，爽得很。

// 原始接口声明
typedef int (*SensorReadFunc)(uint8_t channel, uint16_t *value);

// 真实实现
int real_sensor_read(uint8_t channel, uint16_t *value) {
    // 硬件I2C读取
    return i2c_read(channel, value);
}

// 桩实现
int stub_sensor_read(uint8_t channel, uint16_t *value) {
    static uint16_t fake_data[] = {0x1234, 0x5678, 0x9ABC};
    *value = fake_data[channel % 3];
    return 0;  // 模拟成功
}

// 可切换的调用点
SensorReadFunc g_sensor_read = real_sensor_read;  // 默认指向真实函数

// 测试时切换
void test_setup(void) {
    g_sensor_read = stub_sensor_read;
}

void test_teardown(void) {
    g_sensor_read = real_sensor_read;
}

4.2 条件编译桩：零开销的编译时替换

条件编译桩用预处理指令控制代码走向。说白了就是#ifdef大法。测试时编译桩版本，发布时编译真实版本。

为什么说它零开销？因为条件分支在编译阶段就决定了，运行时没有任何判断。这对资源受限的嵌入式系统特别友好。

// sensor_driver.h
#ifndef SENSOR_DRIVER_H
#define SENSOR_DRIVER_H

#include <stdint.h>

// 测试模式开关
// #define SENSOR_TEST_MODE   // 取消注释启用测试模式

int sensor_read(uint8_t channel, uint16_t *value);

#endif

// sensor_driver.c
#include "sensor_driver.h"

int sensor_read(uint8_t channel, uint16_t *value) {
#ifdef SENSOR_TEST_MODE
    // 桩实现：返回预设数据
    static const uint16_t test_data[] = {100, 200, 150, 180};
    if (channel < sizeof(test_data)/sizeof(test_data[0])) {
        *value = test_data[channel];
    } else {
        *value = 0;
    }
    return 0;
#else
    // 真实实现：硬件读取
    return hal_i2c_read(channel, value);
#endif
}

4.3 链接替换桩：最干净的源码无侵入方案

链接替换桩不碰源码，只动链接器。你把桩函数和目标文件一起链接，链接器会优先选择你提供的符号。

这招在Linux环境下特别好使。我记得有次给一个老项目加测试，源码改不动（领导不让动），就用链接替换桩，把几个底层驱动函数全换了。测试通过后，把桩文件一删，回归真实链接，干净利落。

// 桩文件：stub_flash.c
#include <stdint.h>

// 桩实现：替换flash_write
int flash_write(uint32_t addr, const uint8_t *data, uint32_t len) {
    // 模拟写入，实际只存到内存缓冲区
    static uint8_t buffer[1024];
    if (addr + len > sizeof(buffer)) {
        return -1;  // 模拟溢出
    }
    for (uint32_t i = 0; i < len; i++) {
        buffer[addr + i] = data[i];
    }
    return 0;
}

// 编译命令（GCC示例）
// gcc -c stub_flash.c -o stub_flash.o
// gcc main.o stub_flash.o real_flash.o -o test.out
// 注意：stub_flash.o 要放在 real_flash.o 前面

链接方式	优先级规则	适用场景
静态链接（.o/.a）	先出现的符号优先	单元测试、模块测试
动态链接（.so）	LD_PRELOAD 优先	集成测试、系统测试
GCC wrap 选项	--wrap=symbol 拦截	细粒度符号替换

4.4 宏定义桩：最简单也最危险

宏定义桩就是#define大法。把函数名宏定义成桩函数名，预处理阶段直接替换。

简单是真简单，但危险也是真危险。宏替换是文本级别的，不认作用域，不认类型检查。我曾经见过一个同事，宏定义桩把整个模块的调用链全打乱了，查了两天bug。

// test_config.h
#ifndef TEST_CONFIG_H
#define TEST_CONFIG_H

// 宏定义桩：将真实函数替换为桩函数
#define adc_read(ch, val)  stub_adc_read(ch, val)
#define gpio_set(pin, val) stub_gpio_set(pin, val)
#define uart_send(data, len) stub_uart_send(data, len)

// 桩函数声明
int stub_adc_read(uint8_t channel, uint16_t *value);
void stub_gpio_set(uint8_t pin, uint8_t value);
int stub_uart_send(const uint8_t *data, uint32_t len);

#endif

// 使用方式：在测试文件开头包含
// #include "test_config.h"

4.5 四种技术对比与选型建议

说了这么多，到底怎么选？我个人的经验是：

• 函数指针桩：适合需要运行时动态切换、测试场景复杂的项目。代价是源码要支持指针调用。
• 条件编译桩：适合资源受限的MCU项目，零运行时开销。但需要预埋桩代码，维护成本高。
• 链接替换桩：适合不能改源码的遗留项目，或者第三方库的替换。最干净，但链接顺序容易搞错。
• 宏定义桩：适合快速原型验证，或者小范围替换。简单粗暴，但作用域难控制，容易误伤。