一看到"測試先行"、"測試驅動"這樣的名字，就深深地激起了我強烈的好奇心，開始了自己的探索之旅..
心靈震憾
一段時間的學習，讓我的內心受到了深深的震撼。我們原來的方法居然如此的笨我面對軟件測試先行這一名字時，當時最大的疑問就是"程序都還沒有寫出來， 測試什么呀！"。后來一想，其實這是一個泥瓦匠都明白的道理，卻是自己在畫地為牢。我們來看看兩個不同泥瓦匠是
如何工作的吧：
工匠一:先拉上一根水平線，砌每一塊磚時，都與這根水平線進行比較，使得每一塊磚都保持水平。
工匠二:先將一排磚都砌完，然后拉上一根水平線，看看哪些磚有問題，再進行調整。
你會選擇哪種工作方法呢？你一定會罵工匠二笨吧！這樣多浪費時間呀！ 然而你自己想想，你平時在編寫程序的時候又是怎么做的呢？我們就是按工匠二的方法在干活的呀！甚至有時候比工匠二還笨，是整面墻都砌完了，直接進行"集成測試"，經常讓整面的墻倒塌�？吹竭@里，你還覺得自己的方法高明嗎？
單元測試長期以來被忽視
每一個程序員都知道應該為自己的代碼編寫測試程序，但卻很少這樣做。當人們問為什么的時候，最常聽到的回答就是："我們的開發工作太緊張了"。但這樣卻導致了一個惡性循環，越是沒空編寫測試程序，代碼的效率與質量越差，花在找Bug、解決Bug的時間也越來越多， 實際效率大大降低。由于效率降低了，因此時間更緊張，壓力更大。你想想，為什么不拉上一根水平線呢？難道，我們不能夠將后面浪費的時間花在單元測試上，使得我們的程序一開始就更加健壯，更加易于修改嗎？拋棄原來的托詞吧！
我們的自動化水平太低了
有人還會解釋說，那是因為拉根水平線很簡單，而寫測試程序卻是十分復雜的。我暫且對這句話本身不置可否。不過也體現了一個新問題，我們需要更加方便、省時的編寫測試程序的方法。
要測試一個類，最簡單的方法是直接在調試器中使用表達式觀察對象的值與狀態，你也可以在程序中加上一些斷言、打印中間值等，當然還可以編寫專門的測試程序。但是這些方法都有一個很大的局限性，都需要加入人工的判斷和分析。
由此，自動化測試的引入才是解決之道。正是因為如此，提倡"測試驅動開發"的人群，開發出一系列的自動化單元測試框架xUnit，現在已經有針對Java、Pyhton、C++、PHP等各種常用語言的測試框架。這足以搪塞住那些以"編寫測試代碼太麻煩"為理由的開發人員，讓他們沒有理由逃避單元測試。
正如Robert Martin所說："測試套件運行起來越簡單，就會越頻繁地運行它們。測試運行越多，就會越快地發現和那些測試的任何背離。如果能夠一天多次地運行所有的測試，那么系統的失效時間就決不會超過幾分鐘"。
認清測試驅動開發
測試驅動開發理論最初源于對這些問題的思考：
1）如果我們能夠在編寫程序代碼之前先進行測試方案的設計，會怎樣？
2）如果我們保證除非沒有這個功能將導致測試失敗，否則就不在程序中實現該功能，會怎樣？
3）換一個角度，如果當測試時發現必須增加某項功能才能夠通過測試時， 我們就增加這一功能，會怎樣？
大師們通過帶著這些問題的實踐， 發現這的確是一個提高軟件代碼質量， 使得效率得到保障的一個很好出發點。
文章來源于領測軟件測試網 http://www.k11sc111.com/
