盡管關于測試驅動開發(TDD)的書和文章有成百上千之多，仍然有很多人從未感受過測試的強大力量。

之所以不愿意去寫測試程序不外乎有以下幾個理由：

1. 太費時間。

2. 不值得。

3. 我很懶。

4. 我不知道如何做。

5. 我知道我的程序好用，我運行過一次，沒出問題。

6. 我是超人，我從來不犯錯誤。

除非你的答案是6.(如果是這樣，我很羨慕你)，否則，你應該繼續讀下去。

[[162382]]

讓我們從一個簡單的例子開始。就說你要寫一個Email地址校驗程序。

你也許會使用正則表達式，或手工實現每個字符的對比，來完成這個任務。

現在你想驗證一下你的代碼是否有效。你會怎么做？你可以手工輸入不同的值來驗證它是否符合你的要求，結果你就測試了像下面的這些東西：

foo
foo@bar
foo@bar.baz
...

如果你要改變/調整校驗算法會發生什么？你需要把之前所有的過程全部重復一遍，把每個值都再輸入一遍，看看校驗的結果。如果讓計算機自動的幫你校驗這些是不是會更好些呢？

通過把測試過程自動化，你可以在任何時候對程序進行任何遍次的測試。這不僅僅在以后會節省你大量的時間，而且會增加你的自信心，因為每次當你感覺到程序可能出錯時，只要運行一下你的測試程序，看看測試結果就行了。

現在設想一下你正在編寫一個更加復雜的程序，比如XML解析器。

你不可能編寫出解析器后不去測試它，問題是，你如何測試它？通常，你會創建一個XML樣板文件，把它輸入解析器里，手工檢查解析的結果。當你看到解析器按照要求輸出了你期望的結果后，你確信你完成了任務，解析器沒問題。

問題就在于如果你發現了一個Bug。那你就需要去修改你的代碼，再驗證一次它是否好用。可是我們程序員都是一群懶人，我們會只測試我們遇到的這個Bug，幾乎從來不會去測試解析器的其它部分。這會產生什么問題呢？你能確保沒有把什么東西改壞？

當你寫了單元測試程序后，這個工作流程會變的怎樣？

首先，你已經對程序進行過測試，之前你必須對每個函數進行手工的測試，手工的檢查輸出結果。如果這種事情你只需要做一次，那也沒什么了，但當有東西出錯時，你不想一遍一遍的重復做這個事情，沒有人喜歡來回重復的做相同的事情，特別是無聊的事情。

另一種情況，你為你的解析器里的每個功能都寫了自動測試程序。在這個例子中，你已經測試過你的程序，對這個過程你并不陌生。你需要做的是把手工的檢查改為assertions，它們會為你自動測試程序。

當Bug出現時，巨大的變化發生了。

如果沒有自動化測試，你必須手工的檢查所有的東西來確保你在修正一個Bug時不會引入其它的錯誤。當有數個Bug出現時，你會變得極不耐煩，你開始 不再檢查其它部分的代碼，只關注你的這個Bug。但假如你為程序寫好了自動化測試，你***要做的就是點擊一次按鈕，讓所有的測試程序運行起來，你馬上就能 看到測試結果，幾乎不需要在其它任何事情。

當有了測試程序后，修改Bug是怎樣進行的？

首先，你需要重現這個Bug。無論如何，在你修改前，你必須要認定這個Bug是否真實的存在。如何做到這些？你要寫出一個測試用例來重現這個bug，這個必須要在你做任何的修改這個bug的工作之前完成。

如果這個bug不能重現，問題就可能出自其它地方，如果不能用自動化測試來重現這個bug，你可能在錯誤的地方修改了這個bug，很可能改壞了你的程序。當你寫出測試程序，你必須先運行它確保它會失敗。如果測試沒有失敗，什么地方可能出了問題，你沒能正確的重現它。

當你修改了這個Bug，你也有了針對它的測試程序，你可以立即發現這個bug是否還會出現。

當你這時又發現另外一個bug時該怎么做？

相同的做法。寫一個測試程序，重現這個bug。即使你沒有時間來立即修正這個bug或者這不是個致命的bug，你也應該有個能夠讓它重現的測試程序，當日后你回來解決這個問題時，你就能知道該做什么了。