在解答這個問題之前，來聊聊什么是設計。類、方法命名成什么樣子是不是設計？這個方法隸屬于那個類是不是設計？給這個方法傳什么參數算不算設計？等等等，其實這些都是代碼設計。不只是設計模式那些東西才叫設計。

首先，測試驅動開發中的驅動更多的突出一種以終為始的思想，我們先要弄清楚我們要去哪里？如何判斷我們到那里了？先定義好客戶的驗收標準，在定義驗收標準的時候肯定會驅使我們思考如何設計出方便用戶使用的接口，這樣子我們設計就是被反向驅動出來的。

其次，人是一種趨利避害的高等動物。我們在寫測試的時候，一定會想辦法讓測試更容易編寫，沒有人喜歡在一上路就給自己找麻煩，這就不得不驅使我們寫出更易于測試的代碼，而無數軟件開發實踐證明，利于測試的代碼，它的設計不會太差，那些耦合度高、設計復雜的代碼通常都不易于寫測試（看看沒有自動化測試的遺留系統就知道了）?！盩DD并不會驅動出好的設計，TDD只會給你及時的反饋什么可能是糟糕的設計?！?Kent Beck的這句話，體現的正是這個理。

最后，TDD中有一個核心動作–重構。我們先定義好驗收標準，在定義驗收標準的時候已經來過一輪設計了（接口的定義，類的定義等），然后讓測試快速通過，這兩個過程我們都能夠很好的分離關注點，每次聚焦在一件事情上。通過之后，我們不能就這么過了，還要去停下來去重構實現代碼，這就需要我們對好的設計有一定的理解，能夠識別一些代碼壞味道，識別不良的設計。如果從重構驅使著我們去改良設計，那么TDD的測試先行能夠讓我們的重構充滿信息。從這個層面來講，測試也是在驅動你去改良設計。