TDD之所以讓你安心，主要是每次編寫代碼之后，運行測試會出現一個綠條，告訴你測試通過。這樣，你可以放心大膽的向前繼續，因為你的代碼并沒有破壞任何東西。究竟是什么讓你感到不安，顯然是那些測試沒有覆蓋到的代碼。你又仔細翻看了一下那些沒有測試覆蓋的代碼，你的思路一下子清晰起來。之所以這部分讓你不安，因為里面除了那些確實不好測試的部分之外，里面還有一些邏輯。如果只是那些真正不好測試的部分沒有被測試覆蓋到，你會覺得心里還有一些安慰。你確定了，真正使你不安的就是與不好測試的代碼共存亡的這些邏輯部分。
如果測試可以覆蓋到這些邏輯的部分，至少從感情上來說，就可以接受了。那怎么才能讓這些部分被測試覆蓋到呢？你仔細觀察著那些沒有測試的代碼，如果這樣做，這個部分就可以測試了，如果那樣做，那個部分也可以測試了，一來二去，這些貌似不可測試的代碼可以分解出許多可以測試的部分。
你的心情一下子好了許多，因為這么做終于可以讓測試的覆蓋度達到讓你心理上可以接受的范圍。不過，新的問題也隨之而來。我在做什么？拆來分去，這不就是設計嗎？怎么走到這里來了。我不是在分析單元測試的問題嗎？對了，我最初的問題是TDD，怎么一路跑到設計上來了？
TDD？設計？
你突然發覺自己對TDD的理解有一些偏差。TDD，并不代表不需要設計。讀過很多書的你突然想起了Robert Martin那本著名的《敏捷軟件開發》，上面有一個關于數據庫訪問的例子。那個例子里面，前后兩個版本的差異正好就是考慮設計的結果。通常，在設計中考慮測試，會很容易找到設計中僵硬的部分，讓程序更加靈活。再進一步，如果在開始動手之前，稍微進行一些設計，這些問題還是可能注意得到的。你突然覺得，正是因為TDD本身過于強調測試的價值所在，讓你忽略軟件開發中很重要的部分：設計。
思路一下子清楚起來，TDD其實不只是“紅——綠——重構”，它還是與設計相關的：在動手之前，還是要有一定的設計，而且，在設計中要考慮測試的問題。終于解開了心中的困惑，現在的你，對于TDD有了一個新的認識，雖然這個認識不見得是什么終極真理，但至少是通過自己的思考得來的，這讓你更加相信實踐出真知的道理。
理清思路后，你更加堅信TDD本身的價值所在，也堅定了在日后開發中繼續使用TDD的念頭，當然，目光遠大的你已經盯上了其它的敏捷實踐。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
