前段时间在做一个C++写的DLL(这个DLL中又调用了C写的驱动)的Unit Test,我使用C#来调用里面的API,为了做这个Unit Test,先是根据需求规格说明,设计和其源码设计了多个测试用例,又设计了多个辅助类(包括调用接口,为此还修改了多次C++的代码)来进行每步测试的验证检查,Unit Test的代码也写了快800行经过反复的测试,终于完成了.
想起在大学的时候,在公司做项目(用VB,VC),写好一个组件都要先写个测试程序来测试一番,保证其没有问题,可是实际工作中对Unit Test一直不太重视.最近做这个比较复杂的Unit Test后感觉颇有收获.下面是我搜索到的一些关于Unit Test的Link:
单元测试的六条准则(我粗略翻译了一下):
1. 首先写测试程序
这是XP的格言.先编写测试程序,在有足够的应用程序代码后,使得测试程序能编译通过;然后开始运行测试程序去证明它运行失败,接着继续编写应用程序代码,直到测试程序能正确运行.这个时候,你可以开始写其它的测试程序了.
2. 决不指望编写第一次就能运行成功的测试程序.
在编写好测试程序后,立刻运行之,自然运行失败科学的本质就是弄虚作假.的能力.写一个一开始就能运行成功的测试程序证明不了任何事情.
3. 从零开始,或者一个根本不能工作的用例.
4. 在做测试用例时,别嫌弃做那些琐碎的工作.
5. 松散偶合而且易测试.
为应用程序写高内聚低偶合的组件,这样在测试中就可以这个仿真组件来测试它和其它组件交互的每条路径.而且,在你写了一部份应用的代码后,可以对其进行彻底的测试.
6. 使用仿真对象.
就是仿真特定类型的对象,但实际上是一个接收器,纪录下来那些被调用的方法.
Code Project上也有文章论述Unit Test的:
Writing Your First Unit Test - Design and Strategy
Advanced Unit Test, Part V - Unit Test Patterns - Design and Strategy
