当时我只能简单的解释一下。现在可以多说一些了。
举个例子，单元测试。适合不同语言的工具有一大堆，各个论坛上都能搜到大堆文章。出现频率最高的不外乎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。
其实，无论开发测试，都是为了让人们更好的发挥自身的潜力。开发工程师让人们可以专注于自身的事业而不用过多学习计算机技术；测试工程师让开发工程师可以发挥自身开发的潜力而不用过多参与质量保证的事务。代码高下之分，只能通过让人们发挥了多少潜力来检验。
《神雕侠侣》里提到独孤求败晚年“飞花摘叶皆可伤人”，皆因“不滞于物”，达到“无剑胜有剑”的境界。
所以，开发和测试工程师写出来的代码高下之分，对于这个问题，我会这样回答：皆可伤人，何须理会是花叶还是刀剑；都能发挥人们的潜力，不必关心来自开发还是测试的手笔；优劣之分，或者只来自于用剑者本身。
