一直以來比較推崇在開發中進行全面的單元測試，我覺得單元測試的好處非常多。但是沒有真正的用起TDD，在編寫功能實現代碼之前先編寫測試代碼，這樣的習慣沒有養成，意義也沒有覺得非常大。因此TDD其實沒有真正用起來。直到最近在實際工作中的一個案例讓我更加深刻得領悟出TDD開發的真諦！
案例：最近我們開發一個消息中心的服務，該服務要給數十個項目組提供接口，由於各項目組的進度和步調不一致，消息中心服務的項目先開始工作，定義好了接口之後，將接口公佈出去，然後就開始實現接口功能，進行接口的單元測試及模擬集成測試。一段時間後，陸陸續續有些應用項目組開始工作，發現了接口定義的一些問題，這些問題有的是接口無法滿足他們的需求；有的是有些字段沒有；有的是感覺接口使用不方便；反正最終導致的結果是消息中心服務項目組的代碼進行了多次返工和修改，浪費了很多時間，至今還沒有徹底滿足所有項目組的需求。
後來我接收負責其中一個接口的實現，反思之前出現的問題的原因是什麼？有什麼辦法可以解決或者減輕這種問題呢？我覺得最根本的原因是在設計和實現接口的時候，服務提供項目組沒有讓服務的用戶參與進來一起進行設計，服務接口公佈出去之後，由於服務用戶沒有真正去了解和使用，也無法提出問題，等真正開始使用的時候才發現一大堆問題。因爲接口實現項目組由於知識和場景的完全認識，無法清楚所有使用方的使用場景，因此導致實現的東西與接口用戶想要的東西存在差異的原因。
最終我的解決辦法是也許可以應用TDD的思想。讓接口用戶參與進來共同設計接口，將開發順序反過來結果就完全不一樣。我這次的開發方法是這樣的：首先讓接口使用項目組自己設計協議接口，我來看接口是否存在問題，然後我寫程序實現思路，畫程序的活動圖，用這些東西與接口的用戶溝通，經過協商沒有問題後就這樣定下來了。然後，接口使用項目組開始面向接口編程，當他們的代碼寫完了之後，我再開始寫我這邊的單元測試，接着寫實現代碼，最終進行集成測試。最終的結果證明這種開發方式幾乎沒有返工，開發出來的接口幾乎沒有任何問題。
從這個案例表面看起來好像是接口實現方和接口使用方之間的關係，但是這個道理同樣可以應用到軟件開發者和軟件用戶之間的關係。只有用戶最瞭解自己想要什麼，讓用戶參與進來驗證需求，能夠最大程度的保障需求的正確性。因此TDD能夠將軟件開發方和軟件用戶對需求的理解儘可能保持一致，讓用戶得到他們想要的軟件，他們在自己的使用場景下用起來非常順手的軟件。