TDD好处在哪?是否与自动测试好处混淆

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/IBelieve1974/article/details/54647422

TDD是测试驱动开发,简单理解就是先写测试后写代码。测试case必然是TDD的副产品。传统的瀑布开发模型,是先写代码再写测试。两者开发方式不一样,但是最终都会留下测试集。能自动运行的产品代码测试集就是对于新增代码或重构代码的保护。所以如果只是简单看是否有自动测试集保护代码这个角度来说,保证代码重构,并不是TDD测试现行的独有好处。


那TDD的好处在哪?这个问题把它转化成先写测试的好处在哪?


现有测试会帮助程序员写的代码具备可测试性,这个是天然自带的好处。用TDD方式写代码,程序员没写一段代码的目的就是去pass测试case。一旦测试case pass了。就应该停止写代码,再去写下一个测试case,如此循环。每段代码都可以被测试,自然就有了天然可测试性。


TDD开放方式能让程序员在写代码时候做出好的设计的决定。我是这样理解的,第一测试先行,代码没有的时候,写测试case的依据是什么?只有需求文档。如果后写测试,程序员不仅开需求,而且还会多少受到自己代码影响。即便发现代码有架构上的问题,是否会写出低质量的测试case来为不改架构妥协呢?这样的事情是屡见不鲜的,有些时候不是程序员愿意留一堆烂摊子在那里。而是项目的进度赶在程序员跑。

其次程序员还有一种“快意代码”的情况,也就是写代码是件很爽的事情,有时候对需求还不是很搞得很清楚的时候,就迫不及待动手写代码了。有时候代码写的意犹未尽,代码实现了需求不需要的功能,过度开发了。先写测试case从流程上帮助程序员在写代码前,更深入地搞清楚需求。

第三测试先行会让程序员的代码更加松耦合。每个测试case的目的是相对容易写得比较清晰的。而写代码写得松耦合就需要一定功底。如果写一个测试case然后写一段代码,就自然让这段代码的目标比较单一,只是为pass这个case,减少了代码的辅助逻辑。


TDD是一种灰盒测试,它不像传统的基于function的白盒测试,它只测试对外接口。测试现行迫使程序员率先关注它的对外接口,这就让程序被设计得更加便于调用。


TDD的模式是每个程序员前一分钟的代码是可以运行的。这样就大大减少了程序员debug时间。试想如果程序员开发了几日的代码,做系统调试,是不是会花不少时间debug问题。如果一分钟前程序员的代码是可以运行的,是不是很容易找到这一分钟内的新代码问题?


与TDD对应的模型是DLP Debug Later Programming. TDD的模式不是简单的Coding after Test Case,而是Red-Green-Refactor。注意前两步只是完成了TDD少部分工作,Refactor是更花时间的工作。完整的TDD在第一时间里就完成了局部的重构,减少了技术债务堆积问题。








阅读更多
想对作者说点什么?

博主推荐

换一批

没有更多推荐了,返回首页