飞花摘叶还是重剑无锋[2]

　　在这些信息中可以过滤出用户预先指定的信息，用来拼成另一个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>
CASE>
　　那么只要分析这段XML文本，接下来的事情就跟前面说的一样了。

　　四、 自动运行整个过程

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

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

原文转自：http://www.ltesting.net