当时我只能简单的解释一下。现在可以多说一些了。
举个例子,单元测试。适合不同语言的工具有一大堆,各个论坛上都能搜到大堆文章。出现频率最高的不外乎CppUnit,NUnit,JUnit三种。比起NUnit和JUnit,CppUnit因为C++语言特性的关系,用起来较不方便。
这里我给大家秀一下,解决这个问题,测试工程师会如何的“不择手段”。
单元测试往往需要解决以下几个问题:
1. 用户能在产品代码中指定需要测试的函数
2. 用户能在测试代码中指定需要执行的函数
3. 用户能指定各种控制执行过程的参数,比如优先级、重复、初始化/清理函数等等
其它就先不说了,待会大家就知道再多的都能做到,现在先做到这三个需求就挺不错了。需求1是可选的。Visual Studio从2005开始有这个功能,但是如果没有,估计大家也不会太在意,对吧?
那么,CppUnit如果要做到NUnit和JUnit的样子会遇到什么困难呢?首先就是C++缺乏反射(Reflection)功能。
你看NUnit和JUnit都是定义了一大堆attribute。用户通过为函数指定恰当的attribute,就能标明这个函数需要作为test case执行,之前执行初始化函数Setup,之后执行Cleanup,还有重复100次,优先级2什么的,其它的往上堆attribute就行了。
Visual Studio 2005之后为实现需求1,通过.NET Reflection找出一个类的全部成员函数,然后列个表让你选要测试的函数,最后代码架子都给你搭好。
而CppUnit得用模板,还有另外一个我忘了名字的C++单元测试工具用的是宏。他们费这么些劲是为了什么呢?其实是为了取得这些信息:
具有特定标记的函数的名字或者入口地址/函数指针
附加在该函数上的各种整数,字符串或者函数指针的值
拿到之后呢?CppUnit也好,NUnit或JUnit也好,都是按照取得的信息规划每个函数的执行,保证异常和错误不干扰其它函数的执行,统计整理执行结果和记录日志,没什么区别。
我们来看看,Reflection对于取得那些信息是不是必需的呢?
没错,Reflection是能够在执行时(runtime)取得上述信息,然后在执行时利用它指导test case的执行。
等等,我鸡蛋里挑个骨头:非要把“取得信息”和“指导test case执行”放在同一段执行时期里面吗?或者说,先“取得信息”,停一下,再“指导test case执行”,行不行?
甚至,“取得信息”放在一个程序里先执行,“指导test case执行”放在另一个程序里后执行,又如何?
更甚之,“取得信息”是让别的程序做的,之后让“指导test case执行”捡现成的呢?
可见,Reflection提供了比我们所需要的多得多的功能,实际上我们只需要知道“怎样指导test case执行”就够了。
那可以如何实现呢?
一、 编译链接两次
对,你没听错!编译链接之后除了可执行文件还会产生不少有用信息,最有用的当属PDB文件,包含了所有标识符(Symbol)的信息。Visual Studio 2003开始就带有一个DIA SDK,可以在其安装目录的DIA SDK文件夹下面找到头文件、库文件、COM组件DLL和示例程序。用它分析一个DLL或者EXE可执行文件对应的PDB文件,你可以取得每个编译单元(用.c/.cpp编译得到的obj或者lib)里全部函数的情况,包括函数名字、是否成员函数、返回类型、全部参数的名字和类型、全部局部变量的名字和类型,甚至它在哪个文件的哪一行定义。