在这个部分，我将略述出一些最通用的信任，这些信任来自于在使用大量单元测试获得的好处和解释为什么这些信任通常不是必须真实的。然后我们会帮助您在您的工程中拥有这些信任。
更加简单的跟踪Bug? 当然这并不是必须的，那么您怎么知道您的测试是正确的？ 是否存在在一些测试环节测试失败的情况？另外您又如何知道您的测试覆盖了系统中多少的代码量？是否测试到了程序中的错误，错误又在哪里等等的问题。
当你在你的单元测试中发现了bug后又会发生什么事情哪？你会突然间得到很多与愿意错误的反馈，bug被发现，但是问题并不在你测试的代码中。你的测试的逻辑存在一个bug，因此测试失败了。这些bug也是您最难被检查出来的，因为您通常会去检查您的应用程序而不会去检测你的测试环节。在这部分中，我会展示给你如何确认大量的单元测试，事实上就是使得跟踪bug变得更加容易。
代码更加便于维护 从最终点考虑，你可以倾向于认为这些信任并不是必须的，当然你是对的，让我们去说，代码中每个逻辑方法至少要有一个测试方法（当然，你可能拥有一个以上的方法）在一个好的测试覆盖的工程中，大概有百分之六十的代码是能够得到单元测试的，现在不得不考虑到测试也是要被维护的，如果针对一个复杂的逻辑方法你有20个测试，那么当你向这个方法添加一个参数时会发生什么事情哪？测试无法编译。当你修改了类的结构的时候同样会发生这样的事情。这时你突然发现为了能让你的应用程序继续工作你自己需要改变大量的测试。当然这会花费你大量的时间。
为了使这个信任确认下来，你需要确认你的测试是便于维护的。保持DRY规则写入：不要重复你自己。我们将更加接近的来看这个问题。
代码更加容易被理解? 单元测试的好处通常并非是人们最初所期待的，在一个工程中考虑修改一些你之前从没有看过的代码(比方说,一个特殊的类或者方法).你将如何动手处理这些代码？你可能需要在项目中去浏览这些特定的类或者方法使用的代码，理所当然，单元测试就是这样例子的一个很好的场所。同时，当正确写入的时候，单元测试可以为工程提供一个API文件的容易读取的设置，使得文档的处理和代码的理解对于整个团队中的新老开发者一样的简单，便捷。然而，这些只能在测试是易读的和容易理解的情况下才能被确认，这个规则很多的单元测试开发者并不会遵循。我将详述这个信任，然后在这篇文章的易读测试的部分给你展现如何在去写易读的单元测试。
测试正确的事情
' returns the sum of the two numbers
Function Sum(ByVal a As Integer, ByVal b As Integer) As Integer
你可以向如下的方式写一个失败测试：
<TestMethod()> _
Public Sub Sum_AddsOneAndTwo()
Dim result As Integer = Sum(1, 2)
Assert.AreEqual(4, result, "bad sum");
End Sub
初看上去这个处理像是一个写失败测试的好的方法，它完全错失了你写错误测试的初始点。
文章来源于领测软件测试网 https://www.ltesting.net/