测试驱动开发（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