4.2JUnit框架
单元测试
编写单元测试的目的是为了提高身为一个程序员的生产性能。至于让质保部门开心，那只是附带效果而以。单元测试是高度本地化的东西，每个test class只对单一package运作。它能够测试其他packages的接口，除此之外它将假设其他package一切正常。
功能测试
用来保证软件能够正常运作。他们只负责向客户提供质量保证，并不关心程序员的生产力。它们应该由一个喜欢寻找臭虫的个别团队来开发。这个团队应该使用重量级工具和技术来帮助自己开发良好的功能测试。
一般而言，功能测试尽可能把整个系统当作一个黑箱。面对一个GUI待测系统，它们通过GUI来操作那个系统。而对文件更新程序或数据库更新程序，功能测试只观察待定输入所导致的数据变化。
一旦功能测试者或最终用户找到软件中的一个bug，要除掉它至少需要做两件事。当然你必须修改代码，才得以排除错误，但你还应该添加一个单元测试，让它揭发这只臭虫。
4.3添加更多的测试
观察class该做的所有事情，然后针对任何一项功能的任何一种可能失败的情况，进行测试。这不同于某些程序员提倡的“测试所有public函数”。记住，测试应该是一种风险驱动行为，测试的目的是希望找出现在或未来可能出现的错误。所以我不会去测试那些仅仅读或写一个值域的访问函数，因为它们太简单了，不大可能出错。这一点很重要，因为你如果撰写过多测试，结果往往测试量反而不够。测试的要诀是：测试你最担心出错的部分，这样你就能从测试工作中得到最大收益。
考虑可能出错的边界条件，把测试火力集中在那儿。
寻找边界条件，也包括寻找特殊的、可能导致测试失败的情况。对于文件相关测试，空文件是个不错的边界条件。当事情被大家认为应该会出错时，别忘了检查彼时是否有异常如预期般的被抛出。
不要因为“测试无法捕捉所有臭虫”，就不撰写测试代码，因为测试的确可以捕捉大多数臭虫。
对象技术有个微妙处：继承和多态会让测试变得比较困难，因为将有许多组合需要测试。如果你有三个彼此合作的abstract class有三个subclass，那么你总共有九个可供选择的classes，和27种组合。我并不总是试着测试所有可能组合，但我会尽量测试每一个classes，这可以大大减少各种组合所造成的风险。如果这些classes之间彼此有合理的独立性，我很可能不会尝试所有组合。是的，我总有可能遗漏些什么，但我觉得“花合理时间抓出大多数臭虫”要好过“穷尽一生抓出所有臭虫”。
测试代码和产品代码之间有个区别：你可以放心的拷贝、编辑测试代码。