首页 » 信息技术 »

测试驱动开发(TDD)

2019年10月31日 / 12次阅读

测试驱动开发(TDD:Test Driven Development)作为敏捷开发的一种方式,和传统的敏捷开发模式(开发全部完成后再测试)有所不同。

TDD优点:

把测试部分融入到了开发的每个节点中,边开发边测试,开发完即测试通过。

增加开发人员积极性,目标明确,不写过多代码,满足单元测试和重构代码即可。

重构代码时,不用担心项目报错(可以单元测试的啦)。

能够迅速定位到bug出现位置(单元测试要具体细节化)。

在回归测试会方便一些,因为有单元测试的相关代码。

把测试部分放到了至关重要的部分,传统开发模式中,测试只是一个查缺补漏的角色,现在充当了制定规则的角色(测试人员好开心,翻身做产品的感觉)。

有些开发会对需求理解偏差(人类的惰性,总是喜欢按照自己有利的方式思考问题),所以根据测试用例编写单元测试,在工作开始时就遏制这种情况,不会出现开发完接口发现不符合需求的尴尬情况。

TDD缺点:

对于简单需求,如果还要编写单元测试会增加额外不必要的时间(但是考虑到可能小的需求也会污染其他正常功能,所有最好还是严格按照TDD)额外的单元测试增加开发时间。

 

测试,不仅仅是只有单元测试,直接模拟业务测试也是一种测试。如果软件项目在一开始就严格执行了测试驱动开发的需要,即为各类接口编写测试代码,那比较完美。如果软件项目开始没有编写任何测试代码,在后期某个时点上,还是可以应用TTD的方法。

后期在编写新功能,或者修改已有的功能的时候,针对会涉及到修改的代码,先编写测试代码,实现测试的功能。这相当于写制定这些代码的执行规则。然后再修改这些代码,最后重新测试,确保修改后代码的执行功能与之前的一致。

就算是个人项目,也应该好好执行测试驱动开发的TDD方法。代码一旦多起来,修改造成的影响波及面就大了,如果没有良好的单元测试代码来控制修改过的函数接口,可能容易把代码搞乱。

最后,说一下覆盖率的问题,单元测试并不是要求覆盖所有的函数,有一些代码,本身就不太方便用单元测试的思路来覆盖。我们要看到这一点,单纯地最求测试覆盖率是简单粗暴的,还是要实事求是。

本文链接:https://www.maixj.net/ict/tdd-22964

相关文章

留言区

《测试驱动开发(TDD)》有2条留言

  • 麦新杰

    驾驭更多代码的能力,就要靠TDD这个方法了。 []

  • 麦新杰

    python的unittest模块,正好用来做TDD。 []


前一篇:
后一篇:

栏目精选

云上小悟,麦新杰的独立博客

Ctrl+D 收藏本页

栏目


©Copyright 麦新杰 Since 2014 云上小悟独立博客版权所有 备案号:苏ICP备14045477号-1。云上小悟网站部分内容来源于网络,转载目的是为了整合信息,收藏学习,服务大家,有些转载内容也难以判断是否有侵权问题,如果侵犯了您的权益,请及时联系站长,我会立即删除。

网站二维码
go to top