第 12 章 测试实践

第 12 章 测试实践
你总是可以编写更多的测试。可是，你会很快发现，只有小部分测试（你能想象）是确实有用的。你需要的是编写这样的测试，即使你认为它们应该成功却失败了，
或者即使你认为它们应该失败却成功了。换个角度，考虑术语花费/收益（所指的）方面。你应该编写能回馈信息的测试。
  --Erich Gamma开发期间
      当你你需要改变正在处理的软件的内部结构，以便它更易于理解以及能更轻易地修改而不改变其显著的行为时，一个测试套件在应用这些名为安全
解构
（的变更）方面是无价的。否则，当你实施重构时，你可能不会注意到系统崩溃了。
   
      利用单元测试校验解构的转换步幅确实保持行为（不变）且未引入错误时，下面的情形有助于改善项目的代码和设计：
   

所有单元测试运行正确。

• 
  代码表达了设计原则。
  
• 
  代码没有冗余。
  
• 
  代码包含最少的类和方法。
        需要向系统增加新功能时，先编写测试。那么当测试运行（正常）时你将完成开发。下一章会详细讨论本实践。
     
  调试期间
        当得到一个故障报告，你可能冲动要尽快修复故障。经验表明，这种动力不会带来益处；很可能对故障的修复引起另外的故障。
     
        你可以这样做来把握你的冲动：
     
  
• 
            证实可以再现故障。
          
  
• 
            在代码中找到故障的最小尺度示范。例如，如果一个数字在输出中出现错误，就找到计算它的对象。
          
  
• 
            编写一个自动化测试，它此时失败但是将在故障修复后成功。
          
  
• 
            修复故障。
          
        找到故障的最小的可靠再现给你真正检查故障起因的机会。当修复故障时，你编写的测试将会提高真正的修复它的机会，因为新测试降低了将来的代码改变将修缮复原的可能性。你以前写的所有测试降低了不经意地引发一个不同问题的可能性。
     
  
          单元测试提供很多优势：
          
  
• 
  测试给代码作者和审阅者带来信心，即补丁产生正确的结果。
  
• 
  创作测试用例可以有效地推动开发者发现边界案例。
  
• 
  测试提供了快速捕捉退化的良好方法，并且确保退化不会再次出现。
  
• 
  单元测试为如何使用API提供了可行的范例，并且对于文档方面的努力也非常地有助益。
  

        总之，完整的单元测试降低了任何个体改变的代价和风险。它将允许项目快速、大胆地获得主要架构上的改进。
      
  --Benjamin Smedberg