|
|
英文原文：Testing is waste of time, I know that my code works
盡管關(guān)于測試驅(qū)動開發(fā)(TDD)的書和文章有成百上千之多，仍然有很多人從未感受過測試的強大力量。
之所以不愿意去寫測試程序不外乎有以下幾個理由：
- 太費時間。
- 不值得。
- 我很懶。
- 我不知道如何做。
- 我知道我的程序好用，我運行過一次，沒出問題。
- 我是超人，我從來不犯錯誤。
除非你的答案是6.(如果是這樣，我很羨慕你)，否則，你應(yīng)該繼續(xù)讀下去。
讓我們從一個簡單的例子開始。就說你要寫一個Email地址校驗程序。
你也許會使用正則表達式，或手工實現(xiàn)每個字符的對比，來完成這個任務(wù)。
現(xiàn)在你想驗證一下你的代碼是否有效。你會怎么做？你可以手工輸入不同的值來驗證它是否符合你的要求，結(jié)果你就測試了像下面的這些東西：
foofoo@barfoo@bar.baz...
如果你要改變/調(diào)整校驗算法會發(fā)生什么？你需要把之前所有的過程全部重復一遍，把每個值都再輸入一遍，看看校驗的結(jié)果。如果讓計算機自動的幫你校驗這些是不是會更好些呢？
通過把測試過程自動化，你可以在任何時候?qū)Τ绦蜻M行任何遍次的測試。這不僅僅在以后會節(jié)省你大量的時間，而且會增加你的自信心，因為每次當你感覺到程序可能出錯時，只要運行一下你的測試程序，看看測試結(jié)果就行了。
現(xiàn)在設(shè)想一下你正在編寫一個更加復雜的程序，比如XML解析器。
你不可能編寫出解析器后不去測試它，問題是，你如何測試它？通常，你會創(chuàng)建一個XML樣板文件，把它輸入解析器里，手工檢查解析的結(jié)果。當你看到解析器按照要求輸出了你期望的結(jié)果后，你確信你完成了任務(wù)，解析器沒問題。
問題就在于如果你發(fā)現(xiàn)了一個Bug。那你就需要去修改你的代碼，再驗證一次它是否好用。可是我們程序員都是一群懶人，我們會只測試我們遇到的這個Bug，幾乎從來不會去測試解析器的其它部分。這會產(chǎn)生什么問題呢？你能確保沒有把什么東西改壞？
當你寫了單元測試程序后，這個工作流程會變的怎樣？
首先，你已經(jīng)對程序進行過測試，之前你必須對每個函數(shù)進行手工的測試，手工的檢查輸出結(jié)果。如果這種事情你只需要做一次，那也沒什么了，但當有東西出錯時，你不想一遍一遍的重復做這個事情，沒有人喜歡來回重復的做相同的事情，特別是無聊的事情。
另一種情況，你為你的解析器里的每個功能都寫了自動測試程序。在這個例子中，你已經(jīng)測試過你的程序，對這個過程你并不陌生。你需要做的是把手工的檢查改為assertions，它們會為你自動測試程序。
當Bug出現(xiàn)時，巨大的變化發(fā)生了。
如果沒有自動化測試，你必須手工的檢查所有的東西來確保你在修正一個Bug時不會引入其它的錯誤。當有數(shù)個Bug出現(xiàn)時，你會變得極不耐煩，你開始不再檢查其它部分的代碼，只關(guān)注你的這個Bug。但假如你為程序?qū)懞昧俗詣踊瘻y試，你唯一要做的就是點擊一次按鈕，讓所有的測試程序運行起來，你馬上就能看到測試結(jié)果，幾乎不需要在其它任何事情。
當有了測試程序后，修改Bug是怎樣進行的？
首先，你需要重現(xiàn)這個Bug。無論如何，在你修改前，你必須要認定這個Bug是否真實的存在。如何做到這些？你要寫出一個測試用例來重現(xiàn)這個bug，這個必須要在你做任何的修改這個bug的工作之前完成。
如果這個bug不能重現(xiàn)，問題就可能出自其它地方，如果不能用自動化測試來重現(xiàn)這個bug，你可能在錯誤的地方修改了這個bug，很可能改壞了你的程序。當你寫出測試程序，你必須先運行它確保它會失敗。如果測試沒有失敗，什么地方可能出了問題，你沒能正確的重現(xiàn)它。
當你修改了這個Bug，你也有了針對它的測試程序，你可以立即發(fā)現(xiàn)這個bug是否還會出現(xiàn)。
當你這時又發(fā)現(xiàn)另外一個bug時該怎么做？
相同的做法。寫一個測試程序，重現(xiàn)這個bug。即使你沒有時間來立即修正這個bug或者這不是個致命的bug，你也應(yīng)該有個能夠讓它重現(xiàn)的測試程序，當日后你回來解決這個問題時，你就能知道該做什么了。
it知識庫：“測試是浪費時間，我的程序肯定沒問題”，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
