嵌入式单元测试--框架解析

1.单元测试的必要性

单元测试是软件开发的重要一环，尤其对嵌入式开发。因为嵌入式开发受限于开发环境、调试工具等因素，不能和纯PC软件开发一样使用很多先进的工具。这就需要开发者在开发过程中，进行更细的模块划分，更明确的接口，更详尽的测试。根据软件工程理论，1个bug越是在后期越是花费巨大的成本去修复，并且随着系统复杂度的增长，在一个大的系统中去查找某一个细节具体的问题，相比于在小的模块中去查找问题会花费多倍的时间成本。

2.单元测试框架解剖

一般地单元测试需要实现以下几个基本功能：
1. assert
各种assert，比如AssertTrue、比如AssertFail、AssertStrEquals、AssertIntEquals......
条条大路通罗马，这些Assert有各种功能，其实就是包装了断言的函数。比如AssertStrEquals（str, "open"），进行str和字符串“open”的比较，如果不相同则会报错。
根据框架的结构，在assert失败时候，有的进行长跳转longjmp，有的对类似failCount的全局的变量进行加1并记录错误位置。
2. 错误位置记录
得益于C语言的LINE、FILE宏，这是2个ANSI C标志支持的内置宏定义，可以得到当前的的行数和文件名。 在断言失败的地方，记录文件名和行号，以供用户查询错误的位置。

12	char buf[HUGE_STRING_LEN];sprintf(buf, "%s:%d: ", _FILE_, _LINE_);

3. 测试case管理
这是测试框架区别于自己写的assert测试函数最根本的地方。 测试框架为了提高函数利用率，减少重复，方便测试例程汇总等，都会进行各种封装。比如以下几条。
1）setup和teardown
大部分的测试框架都提供这两个函数，主要是因为有些测试case，有大量重复的代码，比如准备输入数据，测试完毕后清理现场等通用的功能。
2）测试例子汇总
有的叫做TestSuit，有的叫做TestFixtures。把一类相似功能的测试case进行汇总，方便更高层次的调用，也方便用户管理测试例程。
3）测试的调用
多个测试例程汇总后，构成一个数组（表格），启动运行，一般由xxxRun函数负责。
在嵌入式c中，一般都有一个函数指针来操作，这也是为什么所有的测试case的函数名称都使用相同的声明，test_case需要和调用该测试的指针同类型。

4. 测试的执行
测试的执行本质就是函数的长跳转。可以看做在父函数中调用子函数，这个子函数如果是测试例程的话，子函数就会包含assert相关的语句，而assert语句在出错后，会记录错位位置和错误消息，然后进行长跳转（longjmp），longjmp和setjmp（buf）成对出现，返回到调用的位置，然后进行下一个测试case。

    for (i = 0 ; i < testSuite->count ; ++i)
    {
        Test* testCase = testSuite->list[i];
        TestRun(testCase);        if (testCase->failed) {
        testSuite->failCount += 1; 
        }
    }

3. 测试框架的本质

1）为了更好的组织测试，提供的测试组的批量处理功能，一般由for循环遍历一个table数组实现；
2）为了减少重复进行测公用函数提取，比如准备测试环境和清理现场；
3）测试需要的各种断言；
4）断言失败后的跳转、记录错误位置-FILE-, -LINE-宏的使用；
5）测试case运行的监控和结果的汇总。

综上，如果你实现了上面的几个功能，那么也就自己完成了一个测试框架。
其实测试框架是一个很简单的事情，如今测试框架有很多，像VS这样的IDE已经集成了单体测试，所以对于一个开发者怎么规划测试才是测试工作的第一要务。
如何恰当的写测试用例，既不延误开发又不会造成工程臃肿，还能尽可能的覆盖测试范围，这才是测试中最花费功夫的地方。

原文出处