為什麼要使用單元測試

Martin Fowler在《公司專屬應用程式架構模式》一書中說，用領域模型來組織商務邏輯是一個開始使用比較困難，但一旦掌握之後，並體會到他帶來的好處之後，你就會對他愛不釋手，甚至做很小的應用程式也想使用他。（不是原話，但是這個意思）

我覺得TDD也是，讓一個從沒寫過單元測試的人去寫單元測試？太困難了。這個比推廣敏捷設計，svn，重構以及領域驅動設計等都困難的多。因為很多人已經習慣在測試某個功能的時候，運行系統，然後點擊UI，看看有沒有報錯或是結果是否正確。

大家肯定也能找出一大堆的理由來反對TDD。例如，我不清楚單元測試到底是什麼，我不是測試人員，我怎麼會去幹測試的活？寫單元測試花費太多時間了，會影響項目的進度等等。。。

當我還沒有體會到單元測試的好處時（是因為我還沒有真正的使用），在一次會議上我就給我們同事說：我們與其讓我們測試人員進行白盒測試，不如加強我們開發人員的單元測試。雖然我現在還沒有認識到單元測試的好處，但單元測試肯定是對開發和系統的品質是有很大協助的，以後我們要像習慣使用重構一樣使用TDD。

但事實證明，單元測試驅動開發帶來的好處可能比我們想到的還多。

單元測試要從考慮怎麼使用將要開發的這段代碼開始，寫單元測試，然後再寫這段代碼，這樣就明確了這段代碼的使用方式，使代碼更加簡潔，易用，並且明確了設計思路。你不可能讓你的同事去用你寫的自己都認為使用都很麻煩的代碼。
單元測試可以最大範圍的測試邊界條件，特殊條件等，保證了系統的品質。
單元測試為重構後的代碼提供了檢測保證。
單元測試被保留下來，可以反覆的批量測試。
單元測試代碼也明確告訴你的同事，你寫的這段代碼怎麼使用。
。。。。。。

怎樣才能說服你的同事使用TDD呢？
首先你的同事技術水平應該差不多，而且具有上進心。如果他連寫代碼都寫不好，整天渾渾噩噩的過日子。即使再好的技術，再好的開發體驗他也不會有什麼感覺的。
再者就是以一個實際中的編程執行個體給大家講解TDD怎麼幫你完成高品質代碼的。從起初設計，到編寫測試代碼，到明確代碼塊要提供的功能，到編寫代碼，到單元測試，再到重構，再到單元測試為重構的品質把關等等。
還有最重要的一點，就是一定要讓他們親自去嘗試，嘗試過後能體會到其中的價值和好處，他們自然而然的就喜歡上了單元測試。

其實我也是剛開始實施TDD。只是我是自己給我自己推廣，在我不知道TDD會給我帶來多少好處的時候，我就確信他會給我帶來美妙的編程體驗。所以整個過程我都是在自己說服自己，自己強迫自己來做。不過沒有多長時間，能體會到其中的美妙之處，就會喜歡上TDD。

現在我還是一個TDD初學者，在慢慢的體會TDD帶來的好處。。。