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

1.单元测试的必要性

单元测试是软件开发的重要一环，尤为对嵌入式开发。由于嵌入式开发受限于开发环境、调试工具等因素，不能和纯PC软件开发同样使用不少先进的工具。这就须要开发者在开发过程当中，进行更细的模块划分，更明确的接口，更详尽的测试。

传统的开发先出设计方案，而后跟着写出代码，最后在作测试---常被叫作bug调试，因此在代码“写完”以后，还有一半左右的开发量。人都会犯错，在设计和编码中也会犯错，若是后期调试编程去解决设计和编码中引入的错误，那么可能已通过了几天几周几个月，反馈如此只晚，已经不能从错误中吸收经验了，下次还会犯一样的错误。此外根据软件工程理论，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标志支持的内置宏定义，能够获得当前的的行数和文件名。 在断言失败的地方，记录文件名和行号，以供用户查询错误的位置。

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已经集成了单体测试，因此对于一个开发者怎么规划测试才是测试工做的第一要务。
如何恰当的写测试用例，既不延误开发又不会形成工程臃肿，还能尽量的覆盖测试范围，这才是测试中最花费功夫的地方。