单元测试设计模式

单元测试模式

引言

单元测试思想似乎一直引起人们的兴趣，对于那些接收单元测试思想的人来说，一直认同一个观点：要想写一个好的单元测试是很困难的。

面对着开发过程中的效率问题，一直无法避免一个问题：这些测试是否真的值得？也有另一些人在嘲笑着单元测试的思想，特别是“当程序通过单元测试的时候，代码就是好的”这种思想。单元测试有一天也会放入满是灰尘的书架，“它不过是另一个程序工具而已”。

如果要改变这种状况，同行就必须接收单元测试思想。微软的Visual Studio将包括自动重构的工具，很明显自动化单元测试工具将着重于维护和成本，获得更广泛的支持。

然而要使单元测试被广泛接受，单元测试必须被形式化，让它成为一个真正的工程规范而不是一个专门的方法而依赖于程序员个人的不确定性能力。毕竟，单元测试用来测试程序员写的代码，如果程序员一开始就写坏代码，我们就不能指望在测试中有更好的质量。一个概念是：应该首先写单元测试。在代码被写之前，在某个程度上，程序员不仅仅要考虑到代码做什么，也要考虑到代码是怎样被设计。很多人畏惧先写单元测试的思想，那是因为需要在设计工作之前进行预先整理，很多人并不是有意识地认识到他们正在做什么？

到目前为止，还没有一个形式化的单元测试规程，提供一个指南来确保一些单元测试质量的级别。在任何测试被写之前，设计必须达到某种程度的形式化的这个前提条件，会导致困难，因为程序员或者没有形式化设计经验，或者不习惯预先的设计工作。更严重的是预先设计会被重构的假相所替代。

我们需要两件事情，一是建立在单元测试模式之上的形式化的单元测试，二是预先采用面向对象的设计模式应用于开发。要满足单元测试，需要融合面向对象，设计模式和重构。

应当设计一个自动产生单元测试的工具集，带有正向反向的工程过程。对于单元测试来说，对于被测试的代码，应该能够自动产生方法桩，给实施者提供一个测试代码的预期结构和行为的一些文档。

模式分类如下：

1．成功/ 失败模式

2．集合管理模式

3．数据驱动模式

4．性能模式

5．过程模式

6．模拟模式

7．多线程模式

8．压力测试模式

 

1.         成功/ 失败模式：

这些模式是你第一道防线，但不能保证一个好的代码。

 

简单测试模式（Pass/Fail Patterns）

成功/失效模式是最简单的模式。它着重于单元测试的效率，当单元测试通过一个简单测试的时候，它告诉我们被测试的代码运做了。在这种单元测试中，我们给它一个同样的输入，程序给出一样的输出。促发错误的单元测试也一样，给同样一个测试条件，代码正确地陷入了一个错误。

但是在这种情况下，我们没有自信在其它的条件下，代码是否同样工作正常。在其它错误条件下，我们也不能肯定一定进入错误陷阱。

代码通路模式（Code-Path Patten）

简单测试被典型地叫做“黑盒测试”，不检查代码，你能做的是——揣测代码在测试下会面对什么，通过成功和失效用例，来验证那些揣测。

更好的测试保证至少所有的代码通路被执行，这属于白盒测试的一部分，要知道代码的内部工作。这里优先集不是设置条件测试成功/失败，而是设置条件测试代码的路径。对于给定的路径，比较预期输入输出。

怎样我们写白盒测试来测试路径？这样我们就接触到“开始你的代码前进行设计”这种思想。规程是通过强迫预先设计，单元测试能够测试代码路径，实施者不需要做特别考虑。进一步，单元测试文档精确描述代码路径被指望是什么样子的。反过来说，实施期间需要规程，当发现单元测试还有没有被预见到的代码通路，这时就要修正单元测试。

 

参数域模式（Parameter-Range Pattern）

为了改善简单测试模式，确保处理各种各