1、從一開始就保證了代碼的質量。鼓勵開發人員僅編寫能通過測試從而滿足需求的代碼。一個方法的代碼越少，從邏輯上來說，其中包含錯誤的幾率就越小。 ２、無論是有意設計的還是巧合，大多數TDD 開發人員編寫的代碼都遵循SOLID 原則。SOLID 原則是一組幫助開發人員確保編寫出高質量軟件的編程實踐。由TDD實踐生成的這些測試是極為寶貴的，而那些作為副作用得到的高質量也是TDD 難以置信的重要好處。 ３、確保了代碼與業務需求之間的高度一致性。如果需求是以測試方式給出，而且通過了所有測試，就可以很自信地說代碼滿足了業務需要。 ４、鼓勵創建更簡單、針對性更強的庫和API。TDD 對開發過程的改變很大，這是因為那些為庫或API 編寫接口的開發人員就是這個接口的第一用戶。這就提供了有關如何編寫該接口的新視角，而且馬上就能知道這個接口是否有意義。 ５、鼓勵與企業溝通。要創建這些測試，需要多與業務用戶交流。這樣，就可以確保輸入與輸出的組合有意義，還可以幫助用戶理解所開發的產品。 ６、有助于從系統中清除那些沒有用到的代碼。大多數開發人員在編寫應用程序時，設計界面和編寫方法都是以可能發現的情況為基礎的。這樣就會導致系統中存在大量永遠不會用到的代碼或功能。這種代碼的成本非常高，編寫它們需要花費精力，即使這些代碼什么也不做，也依然必須對其進行維護。它還使事情變得混亂，分散開發人員本應專注于重要工作代碼的注意力。TDD 有助于從系統中清除這種寄生代碼。 ７、提供了內置的回歸測試。在對系統和代碼進行修改時，總會創建一套測試，用來確保將來的更改不會損害現在的功能。 ８、終止了遞歸錯誤的出現。可能遇到過這種情景：正在開發一個系統時，相同的錯誤總是一次又一次重復出現。您可能覺得終于抓住并終止了這個錯誤，但在兩個星期之后發現它又回來了。而利用TDD 方法，只要報告了一個缺陷，就會編寫一個新的測試來揭露它。如果通過了這個測試而且一直能通過，說明已經真正消除了這一缺陷。 ９、如果開發應用程序時能夠時刻記著可測試性，所得到的結果就是一種開放的、可擴展的、靈活的體系結構。對于TDD 和松散耦合體系結構，依賴注入都是關鍵組件。這樣所得到的系統，因為其體系結構而變得可靠、易于修改，并能對抗缺陷。