单元测试小技巧[4]

发布: 2010-6-01 11:36 | 作者: 不详 | 来源: 领测测试网采编 | 查看: 37次 | 进入软件测试论坛讨论

　　单元测试小技巧[4] 软件测试　

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

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

　　<TestMethod()> _
　　Public Sub Sum_AnyParamBiggerThan1000IsNotSummed()
    　　Assert.AreEqual(3, Sum(1001, 1, 2)
    　　Assert.AreEqual(3, Sum(1, 1001, 2) ' Assert fails
    　　Assert.AreEqual(3, Sum(1, 2, 1001) ' This line never executes
　　End Sub

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

　　创建易读性测试

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

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

　　<TestMethod()> _
　　Public Sub TestCalcParseNegative()
　　Dim c As New Calc
　　 Assert.AreEqual(1000, c.Parse("-1, -1000")
　　End Sub

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

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

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

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

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

　　<TestMethod()> _
　　Public Sub Parse_NegativeFirstNum_ReturnsSumOfTheRestAsPositive()
    　　Dim c As New Calc
    　　Dim parsedSumResult As Integer = c.Parse("-1", "-1000")
    　　Const SUM_WITH_IGNORED_FIRST_NUM As Integer = 1000
    　　Assert.AreEqual(SUM_WITH_IGNORED_FIRST_NUM, parsedSumResult)
　　End Sub

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

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

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