测试驱动开发简单理解
测试驱动开发(TDD:Test-Driven Development)作为敏捷开发的一种方式,和传统的敏捷开发模式(开发全部完成后再测试)有所不同。
TDD优点:把测试部分融入到了开发的每个节点中,边开发边测试,开发完即测试通过。
增加开发人员积极性,目标明确,不写过多代码,满足单元测试和重构代码即可。
重构代码时,不用担心项目报错(可以单元测试的啦)。
能够迅速定位到bug出现位置(单元测试要具体细节化)。
在回归测试会方便一些,因为有单元测试的相关代码。
把测试部分放到了至关重要的部分,传统开发模式中,测试只是一个查缺补漏的角色,现在充当了制定规则的角色(测试人员好开心,翻身做产品的感觉)。
有些开发会对需求理解偏差(人类的惰性,总是喜欢按照自己有利的方式思考问题),所以根据测试用例编写单元测试,在工作开始时就遏制这种情况,不会出现开发完接口发现不符合需求的尴尬情况。
TDD缺点:对于简单需求,如果还要编写单元测试会增加额外不必要的时间(但是考虑到可能小的需求也会污染其他正常功能,所有最好还是严格按照TDD)
额外的单元测试增加开发时间。
大致TDD工作步骤:
但是完整的测试驱动开发,需要整个开发流程进行改变,所以对于我一个后端开发来说,无法改变团队的情况,所以暂时只是了解这种TDD思想。但是后续开发中,可以针对后端接口先编写单元测试,然后编写只要能通过测试的代码即可(安全性等限制也属于需求内),然后进行重构代码。
https://www.cnblogs.com/zhq3051/p/4596049.html
https://blog.csdn.net/xiyanggudao/article/details/76315271