单元测试中的插桩技术

2022-07-23 1620 words 4 minutes

Contents

1. 背景

在编写C/C++代码的过程中经常遇到需要给代码做单元测试的情况，以此验证代码的逻辑是否符合设计的要求。但是在进行单元测试的过程我们需要对一些外部或者内部的API的行为做一些定制。比如我们在测试过程中需要模拟 malloc 函数分配内存失败的场景，这时候我们应该怎么办呢？又比如我们需要在使用 socket 接口的时候使其返回指定的数据包，那又应该如何做呢？

1.1 常用的方式

在写C/C++代码的时候，我们需要改变API或者是接口的既定行为时通常是使用开关宏来实现的，在不同的运行场景中运行不同的代码例如我们在实现一个对外接口的时候如果使用到了malloc 函数，然后我们单元测试时候需要测试到malloc失败的场景代码实现如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
#ifdef UNITTETS
#define malloc(x) malloc_local(x)
void *malloc_local(unsigned int x)
{
    if (x == 1234)
        return NULL;
    else
        return malloc(x);
}
#endif
char* get_new_buffer(unsigned int size)
{
    char *buf = malloc(size);
    if (!buf) {
        printf("malloc failed\n");
        return NULL;
    }
    return buf;
}
#ifdef UNITTEST
TEST(test, dynamic_buffer)
{
    char *buff = get_new_buffer(1024)
    EXPECT_NE(buff, NULL);
    free(buff);

    buff = get_new_buffer(1234);
    EXPECT_EQ(buff, NULL);
}
#endif

在上面的例子中，如果我们需要改变 malloc 接口的一些行为，那么我们只能使用宏替换的方式去将malloc接口替换成我们自己实现的接口。这样咋看起来好像好像没什么太大的问题，~~又不是不能用~~ 。但是当你细细查看的时候会发现，如果整个代码实现中malloc 有多处被引用，但是我们又不想改变除单侧接口外的 malloc 引用的行为，这时候我们发现好像没有比较优雅的实现方式。这时你可能会说，我们为何不在 get_new_buffer 接口中 malloc 引用的地方使用宏开关来指定单元测试时的实现呢？

1.2 使用插桩的单侧方式

还是上面小节的例子

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
#ifdef UNITTETS
void *malloc_local(unsigned int x)
{
    if (x == 1234)
        return NULL;
    else
        return malloc(x);
}
#endif
char* get_new_buffer(unsigned int size)
{
    char *buf = malloc(size);
    if (!buf) {
        printf("malloc failed\n");
        return NULL;
    }
    return buf;
}
#ifdef UNITTEST
TEST(test, dynamic_buffer)
{
    // hook interface
    xtest_replace(malloc, malloc_local);

    char *buff = get_new_buffer(1024)
    EXPECT_NE(buff, NULL);
    free(buff);

    buff = get_new_buffer(1234);
    EXPECT_EQ(buff, NULL);

    // restore hook
    xtest_retore(malloc);
}
#endif