[讨论问题送Pub币]讨论一下在公司资源有限的情况下怎样开展测试工作

122408644 · 发表于 2007-8-14 21:30

三、测试驱动开发的测试范围

   按大师 Kent Benk 的话，对那些你认为应该测试的代码进行测试，测试驱动开发强调测试并不应该是负担，而应该是帮助我们减轻工作量的方法。

四、TDD的优点

   『充满吸引力的优点』

   完工时完工。表明我可以很清楚的看到自己的这段工作已经结束了，而传统的方式很难知道什么时候编码工作结束了。
   全面正确的认识代码和利用代码，而传统的方式没有这个机会。
   为利用你成果的人提供Sample，无论它是要利用你的源代码，还是直接重用你提供的组件。
   开发小组间降低了交流成本，提高了相互信赖程度。
   避免了过渡设计。
   系统可以与详尽的测试集一起发布，从而对程序的将来版本的修改和扩展提供方便。
   TDD给了我们自信，让我们今天的问题今天解决，明天的问题明天解决，今天不能解决明天的问题，因为明天的问题还没有出现(没有TestCase)，除非有TestCase否则我决不写任何代码；明天也不必担心今天的问题，只要我亮了绿灯。

   『不显而易见的优点』

   逃避了设计角色。对于一个敏捷的开发小组，每个人都在做设计。
   大部分时间代码处在高质量状态，100％的时间里成果是可见的。
   由于可以保证编写测试和编写代码的是相同的程序员，降低了理解代码所花费的成本。
   为减少文档和代码之间存在的细微的差别和由这种差别所引入的Bug作出杰出贡献。
   在预先设计和紧急设计之间建立一种平衡点，为你区分哪些设计该事先做、哪些设计该迭代时做提供了一个可靠的判断依据。

   『有争议的优点』

   事实上提高了开发效率。每一个正在使用TDD并相信TDD的人都会相信这一点，但观望者则不同，不相信TDD的人甚至坚决反对这一点，这很正常，世界总是这样。
   发现比传统测试方式更多的Bug。
   使IDE的调试功能失去意义，或者应该说，避免了令人头痛的调试和节约了调试的时间。
   总是处在要么编程要么重构的状态下，不会使人抓狂。（两顶帽子）
   单元测试非常有趣。

五、TDD的优势

   TDD的基本思路就是通过测试来推动整个开发的进行。而测试驱动开发技术并不只是单纯的测试工作。

   需求向来就是软件开发过程中感觉最不好明确描述、易变的东西。这里说的需求不只是指用户的需求，还包括对代码的使用需求。很多开发人员最害怕的就是后期还要修改某个类或者函数的接口进行修改或者扩展，为什么会发生这样的事情就是因为这部分代码的使用需求没有很好的描述。测试驱动开发就是通过编写测试用例，先考虑代码的使用需求（包括功能、过程、接口等），而且这个描述是无二义的，可执行验证的。

   通过编写这部分代码的测试用例，对其功能的分解、使用过程、接口都进行了设计。而且这种从使用角度对代码的设计通常更符合后期开发的需求。可测试的要求，对代码的内聚性的提高和复用都非常有益。因此测试驱动开发也是一种代码设计的过程。

   开发人员通常对编写文档非常厌烦，但要使用、理解别人的代码时通常又希望能有文档进行指导。而测试驱动开发过程中产生的测试用例代码就是对代码的最好的解释。

   快乐工作的基础就是对自己有信心，对自己的工作成果有信心。当前很多开发人员却经常在担心：“代码是否正确？”“辛苦编写的代码还有没有严重bug？”“修改的新代码对其他部分有没有影响？”。这种担心甚至导致某些代码应该修改却不敢修改的地步。测试驱动开发提供的测试集就可以作为你信心的来源。

   当然测试驱动开发最重要的功能还在于保障代码的正确性，能够迅速发现、定位bug。而迅速发现、定位bug是很多开发人员的梦想。针对关键代码的测试集，以及不断完善的测试用例，为迅速发现、定位bug提供了条件。

   我的一段功能非常复杂的代码使用TDD开发完成，真实环境应用中只发现几个bug，而且很快被定位解决。您在应用后，也一定会为那种自信的开发过程，功能不断增加、完善的感觉，迅速发现、定位bug的能力所感染，喜欢这个技术的。