測試驅動開發（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