码迷,mamicode.com
首页 > 其他好文 > 详细

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

时间:2014-10-20 21:03:11      阅读:118      评论:0      收藏:0      [点我收藏+]

标签:os   使用   for   sp   问题   cti   代码   工作   ef   

 【基本步骤及流程】
     
  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】及帮助类时,可以不写测试,而直接参与到重构过程中。

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

标签:os   使用   for   sp   问题   cti   代码   工作   ef   

原文地址:http://www.cnblogs.com/lovesqcc/p/4038395.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!