需要注意的是，我已经在前面分别实际演示了通过在不同行中创建一个结果变量的方法从声明操作中进行分解操作。这样做至少有两个理由。第一个理由是，你可以为一个变量分配一个可读性强的名字，它可以包含结果，这样可以使你的声明行非常易于理解以及易于读。第二点是，测试下与对象相反的invocation 可能非常的长，它可能会使你的声明行延伸出屏幕的边缘之外，这样导致测试者向右滚屏。就我个人而言，我认为这个是非常恼人的。
我在我的测试中使用了很多常量以确保我的声明读起来像一本书。在先前的例子之中，你可以读到声明中说：“确保分解总数是与忽略第一个数后所得总和是相等的。” 为你的变量取一个很好的名字能够在某些程度上弥补对于测试的命名不足。
当然，有时一个声明 消息是在一个单元测试中传递intent的最好的方法。 一个好的声明消息始终能够解释什么因该会发生或者什么发生了而且为什么会出错。举个例子来说，“分列应该忽略掉第一个数字如果这个数字是个负数的话”，“分列不能够忽略掉第一个负数”，还有“X调用对象Y标记错误”这些都是有用的声明消息，它们很清晰的描述了结果的情况。
在你的设置方法中避免部分相关的代码
一个<TestInitialize()> 方法是样例成员变量在测试中使用的一个好地方。你所有的测试，只有在一部分的测试中避免变量。他们可以为测试设置本地变量。如果你创建了部分相关的实例作为类的成员，用来在测试中简单的避免创建的副本，你应该使用在文章前面解释的工厂方法，使用部分相关变量使得你的代码和设置方法缺少易读性。一旦变量在一个或者每个测试中使用，那么他应该是<TestInitialize()> 方法的一个成员和变量。
Figure 5 展现了一个拥有两个成员变量的类的测试。但是他们中的一个(cxNum)只被部分使用。Figure 6 展现了如何在测试中替换代码从而使它更加易读的方法。
总结
就像你所看到的，写单元测试并不是一个微不足道的任务，如果步骤正确，单元测试可以为开发者的生产力和代码的质量带来令人惊讶的提高，他可以帮助你去创建的应用程序含有更少的错误，同时也可以便于其他的开发者去洞察你的代码，但是他也需要在之前承担一个义务，确认遵循一些简单的规则。当方法并不是很好时，单元测试则可能达到一个相反的结果，从而浪费您的时间，并且使测试过程更加复杂。
Roy Osherove Agile组的负责人, 这个 顾问公司致力于agile software development 和 .NET architecture的研究工作. Roy同时维护了一个blog在 www.iserializable.com上有相关的信息. 你可以通过Email联系他： Roy@TeamAgile.com.
文章来源于领测软件测试网 https://www.ltesting.net/
