成熟
經過了一段時間的迷茫和設計的不斷返工，計劃的不斷延誤。終于開始認清了真相，也真的理解了一句話，"質量是設計出來!"，同時明白了"抽象"的必要性，并且還是會使用MOCK了!
哎~，這些收獲付出了很多的代價呀!項目的合伙人因為計劃不斷厭惡，想殺我心都有，每次去用戶那里，用戶總語氣很怪強調"專家"這兩個字(我朋友為了接項目，忽悠客戶說我是很牛的專家...)，我頂著這些壓力，還在不停的重構，不停的寫著測試代碼。
不過，單元測試的過程并沒有很大的改善，主要還是一個復雜的方法里面的業務規則很多，而且代碼也多，方法內部依賴的環境因素和依賴對象也很多，當出現這種情況的時候，去寫它的測試代碼簡直是一個十分痛苦的事情，而且這種應付不了以后的變化。這種代碼代碼本來就多，當需要變化的時候，看代碼就需要N久時間，更別說還有心情在去理會測試代碼了!我對于這種問題并沒有太多的解決辦法，只是用時間去填補。
其實經過了這些，我知道自己欠缺什么?!那就是設計，由于設計的不夠抽象，對于復雜事物分解的不夠簡單...，接著跑出去書城，拿著剛發的工資買了N多的關于設計的書籍。把它們抱回家，當看著這些書的時候，看著正在進行的項目，和那一大堆比代碼還復雜的測試代碼，覺得值了!
飛躍
"單一職責"
"依賴倒置"
"開放封閉"
"Liskov替換原則"
"迪米特法則"
這些設計的基本原則，大家是否是已經看過了太多次了，但是這些你真的每個都理解了嗎?23種設計模式，每種模式都會了嗎!會使用嗎!你做設計的時候，是否會去思考我應該用何種模式呢?!......
這是我花了N久時間才慢慢理解和學會的東西。時間大概過了半年多，我的小項目已經開始運行，看著它正常的運行和VS2005上測試項目中的一排"測試通過"的標志，無限的喜悅。我學會了設計，理解了測試驅動開發，并且寫測試代碼不在煩惱，而是如此的簡單，"設計完后就馬上去構思測試代碼，如果覺得測試代碼復雜，又回來修改設計，直到交互都簡單為止"，這成為我現在的一種習慣。學會這些的同時我又拿到了項目Money，真是爽呀!
經歷過這些，我的領會是：在做單元測試之前，你必須要學會設計。設計原則和設計模式是你需要要去掌握和理解的，要讓自己在做設計的時候，不會去想"我是否應該用哪種模式"，而已靈活運用，根據具體的情況去做，因為你要做到"無劍勝有勝"!
只有簡單的東西才容易寫，容易測試。代碼變的簡單，單元測試同樣會變的簡單。所以其中最關鍵的就是你如何將復雜的東西簡化。雖然誰都知道這個道理，但是要真正做到還是很不容易的。需要理解，需要實踐，需要時間去積累...
這是我做單元測試，并學會測試驅動開發的一個過程，現在雖然自己還是一只"小鳥"，但是我可以讓代碼看上去簡單，有了一大堆測試代碼的保證，降低了變更的風險。
工作還在繼續，還向著新的目標前進......
文章來源于領測軟件測試網 http://www.kjueaiud.com/