测试驱动开发笔记【初学者】

 【基本步骤及流程】
     
  1. 根据问题进行初始的需求分析，提取出初始而不完备的【to-do】列表；
  
  2. 选择【 to-do】列表中的某个【to-do】， 编写相应的测试；
  
  3. 运行测试，发现无法通过；
  
  4. 作出最简单的的改进，并运行测试使之通过；
  
  5. 一小步一小步地重构代码、运行测试，并使之通过；
  
  6. 跳转至【2】。
  
  
  
  【关键要素】
  
  1.【to-do】列表： 需要完成的任务、当前要做的事情、标识完工。
  
  2. the effective test for the to-do chosen: 为 to-do 列表的 to-do 编写有效的测试；
  
  3. the simplest code for passing test: 使用最简单的方法使测试通过；
  
  4. code refactoring: 通过代码重构，使其符合良好的软件设计理念，并使测试通过。
 

  
    【核心理念】 
  
  1. First Test Then Code: 【先测试后编码】的开发习惯
  
           始终保持【先写测试后编码实现】的开发习惯，这是测试驱动开发的最重要的宗旨。
  
  2. Teensy-weensy Steps: 【一小步一小步、化整为零】的前进策略
  
          ①   始终通过【一小步一小步、化整为零】 的策略来保证均匀地向前推进，不贪求局部快速，但求全局的前进步调。
               
          ②   通过 teensy-weensy steps 可以将复杂的开发、重构过程化解为简单的、容易实现的步骤。
               
   
    【核心理念解析】
    
   1. 测试驱动的开发，其主要意图就是使代码总是处于测试的监督之下。
    
            当进行代码重构和维护时，能够清晰地看到新的代码 对原有系统的影响，能够充满自信地进行重构和维护。
   
   2. 关于【一小步一小步前进，化整为零】的策略：
     
            ①    并不一定总是遵循【一小步一小步】的方式，而是使你【总是能够】一小步一小步的前进，最终达到终点；
                          
            ②   在测试驱动开发的理念中，新添一个小测试，无法通过测试、通过测试，都是向目标前进，都是进步。
      
            ③   如果急切地推进，违背【一小步一小步】的策略，当出现错误而无法通过测试时，就会僵在那里，而无法前进。             
             
           First make it works, Then make it right.
  
  
  
      【基本问题与解答】
      
   1. 如何开始【TDD】 ？  
   
              利用传统的问题分析技能，进行简单而初始的需求分析， 并形成初始的【 to-do】 列表；
                
              该【to-do】列表通常是对问题直观的理解得到的，是不完备的，在【测试-编码-重构】过程中会逐步加以完善。
      
   2. 完成初始【to-do】列表后的第一个步骤？
   
              以第一个测试开始，而不是编写第一个类开始。非常重要，谨记，要克服【先编码后测试】的惯性。
   
   3. 选取【to-do】列表中的哪个【to-do】？
   
              通常选择最容易实现的那个【to-do】，有时也凭直觉，但始终遵循【从最简单的地方入手】的原则。
   
   4. 如何为选定的【to-do】编写有效的测试？
   
              ①  一开始总是编写最直观最简单的测试；
                 
              ②  在代码重构阶段，可能会改变对象接口，从而需要对测试代码进行重构，   使测试仍然执行原有的测试功能，同时更加有效。
   
   5. 如何作出简单的改进尽快使测试通过？
                
              ①  通过构造空实现及存根方法，使测试尽快编译通过，但功能测试将失败；
                
              ②  使用蛮力的硬编码，使用能够想到的最简单的方法，不择手段。
  
   6. 如何重构代码，使测试通过？
   
              这是测试驱动开发的难点；要掌握良好的重构技术和软件设计素养才能更好的做好这一步。
                
               一个比较容易的方法是，一小步一小步地重构，重构之后立即运行测试。            
   
   7. 如何标识完工？
   
               每当通过代码重构使选定【to-do】的相应测试通过时，就从 to-do 列表上划掉它；  直至【to-do】列表上的所有【to-do】都被划掉为止。
                          
   8. 如何标识当前正在做的事情？
   
               在选定【to-do】上作某种标记，比如下划线，圈圈等。
                          
  
                          
      【高级话题及思考】
                
   9. 如何确保【to-do】列表能够完全地覆盖问题所要求的功能及约束 ？
    
           ①  当在开发过程中发现新的需求时，就将它添加到 to-do 列表中；【TDD】的需求分析是渐增式的。
                 
           ②  在所有【to-do】完成之后，还要进行综合测试审核，以保证确实完全地覆盖了问题所要求的功能及约束。
                  
                   【TDD】并不是要消除传统的测试阶段，而是使最后的单元测试、集成测试、验收测试等更容易进行， 降低测试和维护成本。
   
   10. 如何确保【TDD】所获得的软件总体设计是良好的、可扩展性强的？
   
                   【TDD】并非不注重软件设计；它在代码重构过程中引入了软件设计，  从而使软件通过渐增式的【局部最优设计】最终达到【全局最优设计】；这看上去类似【贪心策略】。
   
   11. 在【TDD】中，如何处理需求与测试之间的关系 ？
   
                   【TDD】将需求转化为【to-do】列表，然后进一步转化为测试集合。
                           
                    它将项目任务【以需求为中心】转化为【以测试为中心】，因此，必须保证测试集合的有效性，
                             
                     否则，即使通过了所有的测试，也毫无意义；测试集合必须能够完全表征所有的需求。
   
   12. 在【TDD】中，如何处理测试与设计之间的关系 ？
   
                    【TDD】并没有指明设计与测试之间的关系和先后顺序；
                           
                     测试代码也可能需要重构，以改善测试效果；测试代码的重构将带来产品代码的重构和变化。     
                  
                     测试驱动的开发需要运用大量的重构技术；  而在重构过程中引入良好的软件设计，实际上对软件设计的要求也是比较高的。                       
   
   13. 在【TDD】中，如何界定【一小步】？
   
                    【TDD】并不意味着非要机械地按上述步骤完成；这些步骤仅为初学者设计；
           
                     迭代步骤和节奏，可以根据自己的实际设计和编程水平而有所变化。       
   
   14. 【TDD】适用于哪些场合 ？如何将它运用于大型项目 ？
   
                     ①   对于小型项目而言，【TDD】完全能够胜任；
                                
                     ②   对于大型项目而言， 开发人员个体可以使用【TDD】来完成自己的模块任务；
                                
                     ③   【TDD】中测试、编码、设计工作如何分离和分工呢 ？
   
   15. 【TDD】如何保证测试是有效的 ？         
    
                   测试管理是【TDD】中一个关键点；如果测试不是有效的，就不能保证代码实现了所要求的功能。
                
                   必须有效地将需求转化为测试，使测试能够完全地表征需求。

 

    
        【例外】                          
                           
        ①    有时，需要采取【以退为进】的策略，适当地降低设计的质量，回退到重复代码的状态，
          
                  以另一种重构来寻找突破口。
          
        ②    由于有了详尽的测试以及重构好的干净代码，通常只需要做实验来验证新想法是否可行，
                   
                   不需要绞尽脑汁对系统行为进行推理，害怕重构会破坏原有系统。        
   
        ③    在某些关键点上需要放慢速度，对设计思路进行仔细思量，来写出有效的测试，使接下来的系统构建具有良好的可扩展性；
            
                  即在编写测试之前进行设计考量；此时，可能需要丰富的实际设计经验来引导作出更好的决策。    
                  
        ④     极少量的情况下，会在亮红灯的情况下仍然贸然前进，编写新的测试；
        
        ⑤     编写用于调试的方法【比如 toString】及帮助类时，可以不写测试，而直接参与到重构过程中。