当前位置：网站首页>使用 GoogleTest 框架对 C 代码进行单元测试

使用 GoogleTest 框架对 C 代码进行单元测试

2022-08-10 00:02:00 【独正己身】

在上一篇文章中icon-default.png?t=M666https://meekrosoft.wordpress.com/2009/11/09/2009/10/04/testing-c-code-with-the-googletest-framework/，我描述了如何开始使用 Google 测试框架测试 C++ 代码。在本文中，我将分享一些测试 C 代码的技巧和窍门。

那么有什么大不了的，不就是和C++一样吗？

是的，在某种程度上确实如此，但一如既往，魔鬼在细节中。以下是我们在尝试测试过程代码时面临的一些挑战：

  • 我们无法创建被测代码的实例。这意味着我们不能轻易地为每个测试获取带有初始化数据的新对象。
  • 依赖项是硬编码的。这意味着我们不能使用依赖注入技术来模拟/伪造模块依赖项。
  • 我们不能使用多态来打破依赖关系

所以这只给我们留下了语言中可用的两个依赖破坏工具：预处理器和链接器。

需要注意的事项

静态初始化：在运行每个测试用例之前，您需要能够将数据重置为已知状态。这是将测试彼此隔离的唯一方法。
全局变量：您的模块是否访问全局变量？您需要为此提供一个虚假的实现。
硬件访问：在嵌入式系统中，我们经常有内存映射的硬件寄存器访问。您绝对不想在测试中取消引用随机内存地址。一个很好的解决方法是定义一个通用函数来获取给定寄存器的地址。然后，您可以定义此函数的版本以用于测试目的。

一个例子

那么在实践中看起来如何呢？假设我们有一个用于控制设备的虚构嵌入式软件应用程序：

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
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
#include <stdio.h>
#include <unistd.h>
 
#define IOMEM_BASE 0x2FF
#define VALUE_REG  (IOMEM_BASE + 3)
 
// This must be a power of 2!
#define BUFFER_SIZE 8
#define MAX_ITEMS (BUFFER_SIZE-1)
staticintmy_filter[BUFFER_SIZE];
staticintreadIdx = 0;
staticintwriteIdx = 0;
 
intfilter_len(){ return(BUFFER_SIZE + writeIdx - readIdx) % BUFFER_SIZE; }
 
voidfilter_add(intval) {
 my_filter[writeIdx] = val;
 writeIdx = (writeIdx+1) & BUFFER_SIZE-1;
 if(writeIdx == readIdx) readIdx = (readIdx+1) & BUFFER_SIZE-1;
}
 
#ifndef TESTING
intmyapp_do_dangerous_io()
{
 // lets dereference an io mapped register
 // - on the target it is at address IOMEM_BASE + 3
 return*((int*)VALUE_REG);
}
#endif
 
intmyapp_get_average(){
 intlen = filter_len();
 if(0 == len) return0;
 intsum = 0;
 for(inti = 0; i < len; i++){
 sum += my_filter[(i+readIdx)%BUFFER_SIZE];
 }
 returnsum/len;
}
 
intmyapp_task()
{
 // get value from register
 intnextval = myapp_do_dangerous_io();
 
 // add to filter line
 filter_add(nextval);
 
 // return the average value as the next delay
 returnmyapp_get_average();
}
 
intmyapp_mainloop()
{
 for(;;){
 intnextloopdelay = myapp_task();
 sleep(nextloopdelay);
 }
}
 
#ifndef TESTING
intmain() {
 printf("!!!Hello World!!!\n");
 returnmyapp_mainloop();
}
#endif

我们如何测试这种讨厌的东西？

测试这种性质的代码存在一些挑战，但我们也可以使用一些方法来克服它们。

无限循环：这些家伙会破坏你有效测试的能力。最好的方法是将任何无限循环的主体移动到它自己的函数调用中。
危险代码：您在生产环境中对硬件所做的事情在测试环境中可能很危险。在这个例子中，我们有一个内存映射 IO 地址的硬件访问。我们可以通过三种方式来应对困境：
  1. 更改我们取消引用的地址，
  2. 更改我们调用的函数（在链接时）
  3. 隐藏我们在测试期间使用#ifdefs 调用的函数并提供一个测试假（这是我在这里采取的方法）

不兼容的函数名称：您不能链接两个主要函数。你需要隐藏一个…

静态内存：这确实会损害测试的独立性。您确实应该为每个测试用例重新初始化所有静态数据，幸运的是，有一种简单的方法可以实现这一点。所有主要的测试框架都有一个测试夹具的概念，它允许您在执行每个测试用例之前调用 SetUp 函数。使用它来初始化您的静态数据。请记住：独立测试是很好的测试！

一般测试模式

1. 为您想要存根的依赖项定义假函数
2. 如果模块依赖于全局（喘气！），您需要定义您的假
函数 3. 包含您的模块实现（#include module.c）
4. 定义一个方法将所有静态数据重置为已知状态。
5. 定义你的测试

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
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
#include <gtest/gtest.h>
 
 // Hide main
 #define TESTING
 // Hide the io function since this will segfault in testing
 intfake_register;
 intmyapp_do_dangerous_io()
 {
 returnfake_register;
 }
 #include "myapp.c"
 
 classMyAppTestSuite : publictesting::Test
 {
 voidSetUp(){
 memset(&my_filter, 0, sizeof(my_filter));
 readIdx = 0;
 writeIdx = 0;
 }
 
 voidTearDown(){}
 };
 
 TEST_F(MyAppTestSuite, myapp_task_should_return_correct_delay_for_one_element) {
 fake_register = 10;
 EXPECT_EQ(10, myapp_task());
 }
 
 TEST_F(MyAppTestSuite, myapp_task_should_return_correct_delay_for_two_elements) {
 fake_register = 10;
 myapp_task();
 fake_register = 20;
 EXPECT_EQ(15, myapp_task());
 }
 
 TEST_F(MyAppTestSuite, get_average_should_return_zero_on_empty_filter) {
 ASSERT_EQ(0, myapp_get_average());
 }
 
 TEST_F(MyAppTestSuite, addFirstFilterValAddsVal) {
 filter_add(42);
 ASSERT_EQ(42, my_filter[readIdx]);
 }
 
 TEST_F(MyAppTestSuite, addFirstReturnsCorrectAverage) {
 filter_add(42);
 ASSERT_EQ(42, myapp_get_average());
 }
 
 TEST_F(MyAppTestSuite, addTwoValuesReturnsCorrectAverage) {
 filter_add(42);
 filter_add(40);
 ASSERT_EQ(41, myapp_get_average());
 }
 
 TEST_F(MyAppTestSuite, get_average_should_return_average_of_full_filter) {
 for(inti = 0; i < MAX_ITEMS; i++){
 filter_add(i);
 }
 ASSERT_EQ((0+1+2+3+4+5+6)/MAX_ITEMS, myapp_get_average());
 }
 
 TEST_F(MyAppTestSuite, get_average_should_return_average_of_wrapped_filter) {
 for(inti = 0; i < BUFFER_SIZE; i++){
 filter_add(i);
 }
 ASSERT_EQ((1+2+3+4+5+6+7)/MAX_ITEMS, myapp_get_average());
 }
 
 /// ....test buffer operations...
 ...

这一切都很好，但是<困难的事情>呢？

在谈论测试 C 代码（尤其是嵌入式）时，我经常听到“但是……”

  • 时间问题。没错，单元测试不能神奇地模拟系统的运行时属性。
  • 中断。这是最后一点的特例，但这是所有开发人员在使用多线程时遇到的相同问题。
  • 位正确操作。如果您在 32 位架构上运行 24 位代码，您将不会看到各种溢出、下溢、位移和算术运算的完全相同的行为。
  • 我不可能测试这个！好吧，有些类的代码根本无法使用单元测试方法进行测试。然而，根据我的经验，这适用于大多数代码库中的极少数。秘诀是尽可能多地排除不可能测试的代码，这样你就不会污染代码库的其余部分。

概括

测试 C 代码很难。测试遗留的 C 代码更加困难。但是利用我们在 C 中有限的破坏依赖的语言特性（链接器和预处理器），我们可以完成很多工作。

您可以在 GitHub 上查看原始源代码。

原网站

版权声明
本文为[独正己身]所创，转载请带上原文链接，感谢
https://blog.csdn.net/u012149181/article/details/126034583

边栏推荐

猜你喜欢

随机推荐