更加简单的跟踪bug? 当然这并不是必须的，那么您怎么知道您的测试是正确的？ 是否存在在一些测试环节测试失败的情况？另外您又如何知道您的测试覆盖了系统中多少的代码量？是否测试到了<nobr onmousemove=kwm(2); id=clickeyekey2 style="color: rgb(102,0,255); border-bottom: rgb(102,0,255) 1px dotted; background-color: transparent; text-decoration: underline" onmouseout=kwl(event,this) target="_blank">程序</nobr>中的错误，错误又在哪里等等的问题。 </clk>

当你在你的单元测试中发现了bug后又会发生什么事情哪？你会突然间得到很多与愿意错误的反馈，bug被发现，但是问题并不在你测试的代码中。你的测试的逻辑存在一个bug，因此测试失败了。这些bug也是您最难被<nobr onmousemove=kwm(3); id=clickeyekey3 style="color: rgb(102,0,255); border-bottom: rgb(102,0,255) 1px dotted; background-color: transparent; text-decoration: underline" onmouseout=kwl(event,this) target="_blank">检查</nobr>出来的，因为您通常会去检查您的应用程序而不会去检测你的测试环节。在这部分中，我会展示给你如何确认大量的单元测试，事实上就是使得跟踪bug变得更加容易。 </clk>
代码更加便于维护从最终点考虑，你可以倾向于认为这些信任并不是必须的，当然你是对的，让我们去说，代码中每个逻辑方法至少要有一个测试方法（当然，你可能拥有一个以上的方法）在一个好的测试覆盖的工程中，大概有百分之六十的代码是能够得到单元测试的，现在不得不考虑到测试也是要被维护的，如果针对一个复杂的逻辑方法你有 20个测试，那么当你向这个方法添加一个参数时会发生什么事情哪？测试无法编译。当你修改了类的结构的时候同样会发生这样的事情。这时你突然发现为了能让你的应用程序继续工作你自己需要改变大量的测试。当然这会花费你大量的时间。

为了使这个信任确认下来，你需要确认你的测试是便于维护的。保持dry规则写入：不要重复你自己。我们将更加接近的来看这个问题。

代码更加容易被理解? 单元测试的好处通常并非是人们最初所期待的，在一个工程中考虑修改一些你之前从没有看过的代码(比方说,一个特殊的类或者方法).你将如何动手处理这些代码？你可能需要在<nobr onmousemove=kwm(1); id=clickeyekey1 style="color: rgb(102,0,255); border-bottom: rgb(102,0,255) 1px dotted; background-color: transparent; text-decoration: underline" onmouseout=kwl(event,this) target="_blank">项目</nobr>中去浏览这些特定的类或者方法使用的代码，理所当然，单元测试就是这样例子的一个很好的场所。同时，当正确写入的时候，单元测试可以为工程提供一个api文件的容易读取的设置，使得文档的处理和代码的理解对于整个团队中的新老开发者一样的简单，便捷。然而，这些只能在测试是易读的和容易理解的情况下才能被确认，这个规则很多的单元测试开发者并不会遵循。</clk>