一个测试应该能够自我独立。它不应该与其他测试相关联，也不应该依赖任何具有特殊运行顺序的测试，它应该能够获得你所写的所有测试，可以随意运行所有测试或者只运行其中的一部分，并且是以任何顺序，而且要能够确保它们无论怎样都应该正确的运行。如果你不能够执行这个规则，你将会只在某种特殊的情况下按照预期的表现来运行的状况下结束你的测试。这样子的话，当你在最终期限下与此同时你还想确定你没有向系统之中引进新的问题的时候，当然就会出现问题。你可能很困惑而且考虑着是不是你的代码出现问题，这时，在事实上，问题其实仅仅是你的测试运行顺序所引起的。因此，你可能开始错过了一些在测试中失败的结果而且使它越写越少。这将会是个长期的过程。
如果你从一个测试调出至另一个测试之中，你应该在它们之间创建一个从属关系。你本质上说是在一个测试中测试两个事物（我将会在下一章中解释为什么这会成为一个问题）。就另一方面来说，如果你有测试B，它与测试A 所产生的状态是不相关的，那么你会陷入“顺序”陷阱之中。如果你或者其他人想要改变测试A，测试B将会暂停而且你不知它暂停的原因。对这些故障进行故障处理会浪费很多时间。
使用
在一个单独单元测试中避免多重声明
我们将声明故障看作一个程序弊病的象征且声明被当作软件体的指示点或者“血液检查”。你可以找到越多的症状，程序弊病就越可以轻松的被诊断和排除掉。如果你在一个测试中定义了多重声明，只有第一个故障声明将会以抛出异常的方式显示出来。请参考下面插图之中的测试代码：
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
你可能没有发现以上代码之中其他可能的征兆。在一个故障之后，并发的声明不会被执行。这些不能生效的声明可能提供了有价值的数据（或者征兆）可能能够帮助你很快的集中的焦点而且发现潜在的问题。因此在一个独立的测试中运行多重声明增加了具有很少价值复杂性。另外，声明应该被独立的运行，我们应该设置自我独立的单元测试以使得你具有能够很好的发现错误的机会。
创建易读性测试
如果你以前写过单元测试，你是否在单元测试上写了一个好的声明行？可许不是这样的，大多数开发者并不厌烦去写一个好的声明因为他们更加关心去写测试。
假设你是团队中的一个新的开发者，你试图读一个单元测试。连接这个：
Public Sub TestCalcParseNegative()
Dim c As New Calc
?Assert.AreEqual(1000, c.Parse("-1, -1000")
End Sub
文章来源于领测软件测试网 https://www.ltesting.net/
