迷惘的码农。
分类：
2008-04-02 10:22:17
你总是可以编写更多的测试。可是，你会很快发现，只有小部分测试（你能想象）是确实有用的。你需要的是编写这样的测试，即使你认为它们应该成功却失败了， 或者即使你认为它们应该失败却成功了。换个角度，考虑术语花费/收益（所指的）方面。你应该编写能回馈信息的测试。 | ||
| --Erich Gamma | ||
当你你需要改变正在处理的软件的内部结构，以便它更易于理解以及能更轻易地修改而不改变其显著的行为时，一个测试套件在应用这些名为安全（的变更）方面是无价的。否则，当你实施重构时，你可能不会注意到系统崩溃了。
利用单元测试校验解构的转换步幅确实保持行为（不变）且未引入错误时，下面的情形有助于改善项目的代码和设计：
所有单元测试运行正确。
代码表达了设计原则。
代码没有冗余。
代码包含最少的类和方法。
需要向系统增加新功能时，先编写测试。那么当测试运行（正常）时你将完成开发。下一章会详细讨论本实践。
当得到一个故障报告，你可能冲动要尽快修复故障。经验表明，这种动力不会带来益处；很可能对故障的修复引起另外的故障。
你可以这样做来把握你的冲动：
证实可以再现故障。
在代码中找到故障的最小尺度示范。例如，如果一个数字在输出中出现错误，就找到计算它的对象。
编写一个自动化测试，它此时失败但是将在故障修复后成功。
修复故障。
找到故障的最小的可靠再现给你真正检查故障起因的机会。当修复故障时，你编写的测试将会提高真正的修复它的机会，因为新测试降低了将来的代码改变将修缮复原的可能性。你以前写的所有测试降低了不经意地引发一个不同问题的可能性。
单元测试提供很多优势：
总之，完整的单元测试降低了任何个体改变的代价和风险。它将允许项目快速、大胆地获得主要架构上的改进。 | ||
| --Benjamin Smedberg | ||
