单元测试小技巧(5)

　　在一个单独单元测试中避免多重声明

　　我们将声明故障看作一个程序弊病的象征且声明被当作软件体的指示点或者“血液检查”。你可以找到越多的症状，程序弊病就越可以轻松的被诊断和排除掉。如果你在一个测试中定义了多重声明，只有第一个故障声明将会以抛出异常的方式显示出来。请参考下面插图之中的测试代码：

　　你可能没有发现以上代码之中其他可能的征兆。在一个故障之后，并发的声明不会被执行。这些不能生效的声明可能提供了有价值的数据(或者征兆)可能能够帮助你很快的集中的焦点而且发现潜在的问题。因此在一个独立的测试中运行多重声明增加了具有很少价值复杂性。另外，声明应该被独立的运行，我们应该设置自我独立的单元测试以使得你具有能够很好的发现错误的机会。

　　返回页首

　　创建易读性测试

　　如果你以前写过单元测试，你是否在单元测试上写了一个好的声明行?可许不是这样的，大多数开发者并不厌烦去写一个好的声明因为他们更加关心去写测试。

　　假设你是团队中的一个新的开发者，你试图读一个单元测试。连接这个：

　　作为一个简单的练习，如果你理解了上例中Calc分列方法的用法，你很可能可以进行很好的推测，但是他可以简单的作为人员数量的用例使得输出结果为1000:

　　在组中返回最大的负数作为一个正数。

　　如果数字是负数且返回值为剩下几个数的总和作为一个正数，那么忽略第一个数字。

　　返回相互作乘积运算而得的数字。

　　现在请参考下面在单元测试之中的小改动：

　　这个是不是比较容易理解呢?当声明消息消失之后，表达意图最合适的地方就是测试的名字。 如果你广泛的使用了它，你将会发现你不再需要读测试代码就能明白代码测试的目的所在。事实上，你经常根本不需要写任何注释，因为代码，特别是那些带着实例的，他们自己是证明自己的。

　　名字包含了三部分内容： 测试下方法的名字(解析)，测试下的状态或者规则(带着第一个负数传递一个字符串)，以及预期的输出或者运行情况(剩余数字的总和以一个正数的形式返回)。需要注意的是我从名称中将Test以及Calc这两个词删除。我已经知道这是一个属性的测试因此在此没有重复此信息的必要。我也知道这是一个在 Calc类中的测试因为测试类经常是写给一个特殊类的(这个类也许已经被命名为CalcTests)。

　　名字也许会很长，但是又有谁在乎呢?它读起来更像是一个标准英语的句子而且它使得一个新来的开发者更容易明白测试的内容。更是这样，当这个测试发生故障时，我们甚至不需要调试代码就可以知道问题究竟出在哪里。

　　需要注意的是，我已经在前面分别实际演示了通过在不同行中创建一个结果变量的方法从声明操作中进行分解操作。这样做至少有两个理由。第一个理由是，你可以为一个变量分配一个可读性强的名字，它可以包含结果，这样可以使你的声明行非常易于理解以及易于读。第二点是，测试下与对象相反的invocation 可能非常的长，它可能会使你的声明行延伸出屏幕的边缘之外，这样导致测试者向右滚屏。就我个人而言，我认为这个是非常恼人的。

　　我在我的测试中使用了很多常量以确保我的声明读起来像一本书。在先前的例子之中，你可以读到声明中说：“确保分解总数是与忽略第一个数后所得总和是相等的。” 为你的变量取一个很好的名字能够在某些程度上弥补对于测试的命名不足。

原文转自：http://www.uml.org.cn/Test/200605091.htm