单体测试是敏捷软件开发的支柱之一。最早由KentBeck提出，如今单体测试已经进入了很多组织的系统和核心。单体测试帮助工程师减少缺陷数目和调试时间并有助于开发更健康、更稳定软件。

　　在本文中我们将探讨软件工程师在任何编程语言或环境中都可以应用的12条单体测试建议。

　　1.使用单体测试管理风险

　　一个新手可能会问为什么我要写单体测试？的确，难道测试不是软件工程师都想外包给QA人员的枯燥的东西吗？这是一个在现代软件工程中不复存在的思维定势。软件团队的目标是开发出最高质量的软件。消费者和商务用户可能在80年代和90年代还能容忍“蹩脚”的软件。但随着大量库、web服务以及支持重构和单体测试的集成开发环境的出现，现在已经无法为软件的缺陷找借口了。

　　单体测试背后的思想就是为每个软件组件创建一套测试。单体测试使得持续软件测试（continuoussoftwaretesting）成为可能，因为较之手工测试，重复运行它们很廉价。

　　在你的系统扩展的同时，单体测试也不断扩展。每个测试都是系统可以运行的保证。代码中的缺陷就意味着风险。利用单体测试集，工程师可以使得缺陷数目和未测代码的风险大大降低。

　　2.为每个重要组件写一个测试用例（TestCase）

　　在你开始写单体测试的时候，试问自己我需要些什么样的测试？

　　最初的动机可能是写一堆功能测试。比如，检查系统不能功能的测试。这是不对的。正确是做法是为每个重要组件创建一个测试案例（一套测试）。

　　每次测试的关注是单个组件。在每个组件内部寻找一个接口——该组件公开暴露的行为的集合。你必须为每个公开的方法写至少一个测试。

　　3.创建虚的测试用例（TestCase）和测试工具（TestUtilities）

　　对于任何代码都可能有所有测试都需要做的共通的东西。首先针对开发语言选择一个测试框架。比如，在Java界工程师会使用Junit（一个使用Java编写测试的简单但又强大的框架）。该框架带有TestCase类作为所有测试的基类。通过添加适用于环境的方法和工具，所有你的测试用例都可以共享这些共通的基础设施。

　　4.编写聪敏的测试

　　测试很耗时间，所以应该确保它们有效。好的测试通过最少可能的代码检测每个组件的核心行为。例如，没有必要为JavaBeansetter和getter方法编写测试，因为这些会通过其它方法测试到。

　　反之，应该编写关注系统行为的测试。你没有必要做到面面俱到。创建那些进入脑海的测试并随时准备在重新回来时加入更多测试。

　　5.为每个测试准备干净的环境

　　软件工程师一直都关注效率，所以当他们听说需要给每个测试单独准备环境时他们很担心性能。但是正确地从头开始准备每个测试很重要。你最不想要的就是因为适用了其他测试的遗留数据而导致的测试失败。确保每个测试都合理设置并不要去担心效率。

　　当你有了一个所有测试的共通环境时你可以在测试基类中加入静态的设置代码块（staticsetupblock）。