飞花摘叶还是重剑无锋

        有来面试的同行问个一个问题：“如果微软的开发和测试工程师都需要写代码，那么两者写出来的代码有高下之分吗？”

当时我只能简单的解释一下。现在可以多说一些了。

举个例子，单元测试。适合不同语言的工具有一大堆，各个论坛上都能搜到大堆文章。出现频率最高的不外乎 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 ）里全部函数的情况，包括函数名字、是否成员函数、返回类型、全部参数的名字和类型、全部局部变量的名字和类型，甚至它在哪个文件的哪一行定义。

在这些信息中可以过滤出用户预先指定的信息，用来拼成另一个 C/C++ 源文件，这个源文件叫做执行表，里面包含了所有需要执行函数的名字列表以及各项参数的静态定义。“指导 test case 执行”是可以预先分离实现的模块，把它 include 进来即可。最后，把原先用来产生可执行文件的全部文件，把定义 main 或者 DllMain 的那个源文件，改为执行表，再编译链接一次，大功告成。

问题是怎样产生第一个可执行文件呢？用户使用单元测试工具的时候不都实现了一些函数吗？那就能产生用户的编译单元。我们可以预先提供一个定义 DllMain 的壳 lib ，它与用户的编译单元链接在一起就成为被 DIA SDK 分析的 DLL 。然后像前面说的，最后换成执行表的编译单元。

你注意到了吗，用这个方法，别说 CppUnit ，做 CUnit 都可以。

二、     用 struct 表达 attributes

刚才并没有提到如何像 NUnit 和 JUnit 一样取得 attribute 所定义的信息。我们要求需要执行的函数定义成返回 BOOL 类型，只有一个参数，一个结构的指针。

如果用户定义的这个结构像这样

    struct SIGNATURE_001

    {

        SIGNATURE_001()

        {

            const char* title = "Test case 1";

            const DWORD priority = PRIORITY.P1;

            const char* Setup = "MySetup";

            const char* Cleanup = "MyCleanup";

           …

        }

};

用 DIA SDK 分析就会发现，这个函数的参数类型具有构造函数，其中有局部的常量名字如何，值多少。依靠这些信息，我们足可以判断一个函数是不是需要执行，所需要的参数都是怎么样。

为了简化，我们可以用一个简单的宏帮助定义这一切，放在函数前面就可以了。当然它不是必需的。

在 C 下面可不能这么用，但办法还是有的。

三、     用注释表达 attributes

既然我们能把函数定位到某一行，那么往前扫描源文件行，遇到三个斜杠开头的就滤掉“ /// ”读进来，如果我们预期这些注释看起来是这个样子

    /// <TestCase>

    ///     <Title>Test case 1</Title>

    ///     <Priority>1</Priority>

    ///     <Setup>MySetup</Setup>

    ///     <Cleanup>MyCleanup</Cleanup>

    /// </TestCase>

那么只要分析这段 XML 文本，接下来的事情就跟前面说的一样了。

四、     自动运行整个过程

用户需要的是写好测试代码，执行一个命令就能得到所有可执行代码。我们可以利用 makefile 把这一切连接起来：先写好需要分析的 DLL 的依赖关系，然后让执行表依赖上述 DLL ，命令为执行分析代码产生执行表，最后让目标 DLL 依赖执行表即可。又或者用 Visual Studio 的 Build Steps 来驱动也可以。

到这里，大家可以看到，为了实现最终目的，我们突破了习惯的限制（只使用语言特性），并且充分利用现有的技术和工具（ DIA SDK 和 XML Parser ）。只要能实现目的，“无所不用其极”。

你可能觉得折腾这么一套东西动作也挺大的。我得说，“看菜吃饭”。

另一个例子，有一个测试框架，万事俱备，就是没法把 test case 自动传送到 Apple Macintosh 的机器上。现有的代码可以让 test case 在 Apple Macintosh 上执行，也可以把 test case 从服务器下载到 Windows 测试机器上发动执行，但是没法跟 Apple Macintosh 交流。

怎么办？在 Apple 上开发谁都不懂。在 Apple Macintosh 上写一个客户端跟服务器交流，够忙半天的了。面对一整套已经完备的测试框架，让它尽快用于新的环境，比做什么都重要。

别人告诉我，可以 Apple Macintosh 上开一个共享夹，然后 Windows 的机器可以用 UNC 路径往里面读写文件。

OK ，这就足够了。 Windows 测试机器上发动执行的只是一个脚本，把需要用到的文件往指定 Apple 机器的共享文件夹上写。写完之后再写一个文件，名字是约定好的，例如“ ready ”，里面包含启动 test case 的命令行。然后不停的隔一段时间检查共享文件夹里面一个叫做例如“ done ”的文件，出现之后把它作为结果返回服务器，最后把它和其它文件都删掉，退出。

Apple Macintosh 上面则运行另一个脚本，始终不退出。它不停的隔一段时间检查其指定的共享文件夹里面一个叫做“ ready ”的文件，出现之后执行里面的命令并且等待它结束。这个命令必须生成一个叫做“ done ”的文件，包含执行结果。然后，不停的隔一段时间检查“ done ”是不是还在，不在了就回到最初的检查“ ready ”的代码。

这就足够了。两个脚本加起来 50 行不到。

你觉得它太粗糙了吧？这么简单的协议？

事实上，它并不需要十分健壮。

一、     Windows 和 Macintosh 双方的网络文件系统协议解决了很多问题

二、     测试机器是不会有人去用的，你可以安全的假设只有你的程序在执行

三、     服务器和 test case 都已经测试过，他们应该负担起若干健壮性的需求。事实上，他们比这两个脚本更适合做这个，不是吗？

这就是“看菜吃饭”：不需要的功能，是不需要去实现的，无论它看上去有多么的 cool ；必需的功能，无论如何都要做到，无论它看上去有多么的 boring 。

其实，无论开发测试，都是为了让人们更好的发挥自身的潜力。开发工程师让人们可以专注于自身的事业而不用过多学习计算机技术；测试工程师让开发工程师可以发挥自身开发的潜力而不用过多参与质量保证的事务。代码高下之分，只能通过让人们发挥了多少潜力来检验。

《神雕侠侣》里提到独孤求败晚年“飞花摘叶皆可伤人”，皆因“不滞于物”，达到“无剑胜有剑”的境界。

所以，开发和测试工程师写出来的代码高下之分，对于这个问题，我会这样回答：皆可伤人，何须理会是花叶还是刀剑；都能发挥人们的潜力，不必关心来自开发还是测试的手笔；优劣之分，或者只来自于用剑者本身。