为什么要单体测试?
来自全世界范围的项目数据表明尽管行业整体有了进步，但还是有很多项目失败了，更多的项目延后完成或者超支。随着商业的加速，软件开发团队需要应对企业所需的软件交付做出更快响应。
越来越多的开发团队都想变得更敏捷并都努力满足相关联的三个目标:
更快的市场交付: 太多开发和质量保证的周期都消耗在“关心”脆弱的遗留应用程序了（是的，即使Java也是这样——遗留代码不再仅仅是COBOL。它指的是任何创建时不带有自信容易地改动代码所需要的详细测试的代码）。目前遗留代码的问题使得企业发展变慢，并且更加难以实现它的承诺。
更高质量: 团队经常发布缺陷超出他们预期的代码，从而导致更长和更昂贵的质量保证周期和交付给最终用户的更多缺陷。大家太过关注除去缺陷的测试，而不是从头开始就编写没有缺陷的代码。
更柔韧: 很多遗留系统都很脆弱并且没有增强的韧性。如果你害怕改变业务所依赖的代码就很难使业务变敏捷。
为了编写更好的代码并使得既有的代码更好，从而你更快交付更多的软件，你能做些什么呢？
结果呢？你的团队承受巨大的压力并感到没有任何办法。有办法吗？让我们看看软件开发是怎么回事，怎么让它变得更好？
目前大部分软件都是临时编码、测试后交给质量保证团队。他们会发现缺陷并报告给开发者。但是在流程的后期修改缺陷既浪费时间又浪费钱。行业研究显示修改一个缺陷的成本在软件生命的各个周期之间是以数量级增长的。这就意味着QA阶段修改一个缺陷的成本会超过开发阶段修改缺陷成本的100倍。该低效的工作流程使得软件延期并很昂贵。
越来越复杂使得软件有很多缺陷
随着Java软件项目的规模越来越大，面向对象代码的代码的测试越来越复杂，当今的应用程序通常有几百万的状态组合和路径。质量保证人员无法通过代码想象到每个可能的状态，每个可能的数据值以及每个可能的路径（更不用说测试了）。
系统测试总是会有忽略之处。系统越复杂，被忽略的缺陷就会越多。不断增加的复杂性导致软件没有被充分测试并最终在未知缺陷数目的情况下发布。
权宜的修改让软件没有韧性
开发者凭经验知道遗留应用程序的代码很脆弱。他们知道这些是因为每次他们动这种代码时都会有新的缺陷出现，并且他们缺少有效地捕捉这些回归的工具。
通常，开发者必须采用“局部修复”（也称为骇客、凑和、权宜的修改）以使得造成的损害尽可能小，而不是重新设计或者重构遗留应用程序。即使开发者很小心，回归还是会发生，而且它们之中的很多直至客户报告了问题后才被注意到。随着时间的流逝，这些局部修复的累积会使得遗留代码更难以提高。越多骇客的修改，就越不柔韧。
单体测试就是解决之道
单体测试是改善市场交付时间、质量和柔韧性的一个简单但很有效的思想。关键的思想就是每段代码需要相应的代码，测试代码最佳人选就是写代码的开发者。让开发者在写代码的时候测试他们的代码可以确保从头开始就有质量。有了单体测试就可以更容易更安全地修改代码，因为测试记录并保证预期的行为并可以立刻发现回归。
自动化帮你做到这一切
单体测试是正确的事情，但并不容易。理想情况下，每个开发者都应该在编写每个方法和类的时候写一套测试来验证。定位高风险区域、编写测试、运行测试、监测结果以及 确定进一步测试的区域都需要时间。而且对于任何人来说都很难想象那些意外的、从来没 有遇到过的事情。自动化可以帮忙做到这点。实际上，这很重要。
