CppUnit的缺陷

上一篇我们介绍了CppUnit以及它的一些重要理念（参见《CppUnit与单元测试》）。然而在使用CppUnit的过程中，我还是遇到了一些不如意的地方。这里，我们就要讨论下我看到的CppUnit存在的一些不足，以及我在WINX中对它作出的改进。 

CppUnit提供了自动化、安全可控的执行环境。这是它的精华。然而它的问题在于，在测试案例执行失败，也就是说当模块存在bug时，没有一个很好的方式去跟踪它。展开来说，主要的问题有两点：

1、虽然CppUnit的出错报告中给出了错误所在的文件以及行号，但是这个信息并不方便，也不充足。 

不方便之处在于，我得找到相应的文件，然后打开它，定位到出错的行，设置断点，跟踪。有没有可能做得更加方便一些？不充足之处在于，也许出错行并不是每次执行都出错，而是在n次执行的时候出错。那么直接跑到出错行设断点，不是什么好主意。

我们知道，MFC的ASSERT（或者ATL的ATLASSERT）很好用，因为它在断言失败时可以停下来，进入调试状态。有没有可能，CPPUNIT_ASSERT也可以在出错的时候停下来？嗯，好像不行？CppUnit强调的是自动化，如果停下来就麻烦了。——各位读者想到可什么主意了？

2、一个测试程序有很多个测试案例，在某个测试函数存在bug时，其实我们跟踪调试的时候，并不喜欢所有的案例一起执行，而只希望执行有问题的案例。

特别是每个案例执行时间如果较长，那么漫长的等待也许让你有挫伤感。另外的问题是，也许几个案例测试的是从不同角度去测试同一个功能（函数），这样你设置的断点可能经常被那些没有bug的案例干扰。这些问题都导致了不愉快的体验。那么怎么办呢？把其他案例都注释掉？也许一直以来你都这样去做了。可有更好的办法吗？

WINX对CppUnit的改进

下面我们看看WINX中是如何支持单元测试的。当然更重要的是，如何解决上面的这些问题的。

 我曾经基于CppUnit写过一个增强版本的CppUnit。这个版本的CppUnit引入了两个概念（注意下面列了3条。第3条是写WINX时引入的）：

1、引入调试模式。

在调试模式下，CPPUNIT_ASSERT的行为与ASSERT/ATLASSERT一致，也是弹出断言对话框。而在普通模式下，则CPPUNIT_ASSERT报告案例执行错误，并不停下来。

2、引入案例执行的过滤条件。

也就是说，你可以选择只执行符合特定条件的案例。

3、把代码和针对该代码的测试案例写在同一个文件里。

写WINX的时候，我为是否要把CppUnit引入到WINX中，仔仔细细考察了下CppUnit。最终我决定，依据CppUnit的思想，写一个mini版本的CppUnit，而不直接基于CppUnit。

这是因为，WINX的单元测试观念在CppUnit的测试理念之上，加了一条：

• 把代码和针对该代码的测试案例写在同一个文件里。

这样做的好处是：

• 你不容易忘记修改好代码后，去执行下相应的案例。
• 你的代码规格改变后，你需要顺手修改一下测试案例的代码，以便它可以编译通过。
• 测试案例一定程度上起到了示例代码的作用。

WINX的单元测试样例