一、寫在前言
- 作為開發人員，我們都知道我們應該測試我們的程式碼。我們應該寫單元測試，但這也通常是我們發現沒時間時跳過的第一步。
- 作為團隊的領導者或者管理者我們都知道測試是必要的，但是當截止日期臨近的時候，我們傾向於減少測試，而把更多的重點放到編碼上。這樣看測試領域似乎很緊張。我們都知道測試對我們是有利的，但是一旦專案面臨壓力時我們就不再測試了。
二、我們為什麼測試?
Edsger W Dijkstra 說過:測試可以用來找到顯式的缺陷（bug），但是無法顯示潛伏的軟體缺陷（bug）。這意味著測試不能百分百保證你的軟體沒有缺陷（bug），但是它確實很有幫助。
我們也可以換種說法，如果我們不進行測試我們幾乎可以百分百保證我們的軟體會有缺陷（bug），除非我們是在編寫像“hello world！”那樣簡單的程式。但是即使這麼簡單的程式你也會測試，因為一旦你輸入完你的程式碼你就會很好奇它的輸出是不是真的是“hello world！”。
而這就是第一類形式的測試，也是我們一直在做的: 手工測試. 我們編寫程式，然後啟動它去檢驗執行結果。 對於一個簡單的“hello world”這可能是足夠的，但是對於複雜度更高的程式這可能會導致時間的浪費，這是對一個已知的行為結果集的手工重複。這難道不是我們發明計算機的初衷嗎?
對於“hello world”這不是大問題，但是當你建立一個 web 應用時，測試場景是在翻頁十次，點選某些按鈕，在大量表單中輸入（正確的）資料之後再測試某些特定條件，你就看到自動化會節省大量的時間。如果你能通過測試執行器（testrunner）直接執行你想要測試的函式，而不是必須花費半分鐘手工執行到那個函式，你會節省很多時間！但這也意味著我們需要多一點點程式設計，而更多的程式設計意味著更多的時間和精力。所以它會花費更多的時間而你的專案可能因此完工的晚些。
三、也許未必
讓我們建立一個控制檯應用程式來計算最大公約數(GCD)的兩個整數。有很多方法可以解決這個問題，但為簡單起見，我們將
1.輸入兩個整數
2.不管其演算法怎麼樣，計算一下 GCD
3.顯示輸出
讓我們瀏覽一下正常的開發週期。我們通常寫一個 main() 函式，得到了兩個整數，以及呼叫一個函式來計算一下 GCD，然後顯示結果。測試。在你的控制檯中輸入 2 個整數會花一些時間，這將變得相當無聊，如果你需要多次重複你的程式碼。這也很容易在控制檯應用程式中輸入出錯，導致程式崩潰。這意味著你必須重新啟動程式，輸入兩位數，然後再次驗證結果。請你要記住，我們討論的是一個控制檯應用程式，只需要兩個輸入值，不需要點選(在 web 應用程式中)，我們已經看到，這將需要花費一些時間。
然後，我們很可能會想要測試一些更多意味著重啟程式的值，進入兩位數（正確地），然後測試。。。所以我們即使看到也不會立即這樣做，因為它要花費太多的時間。Edge 案例將會被遺忘，錯誤只會在生產中被發現！此外，當我們改變一些我們需要再次執行所有的測試(手動)，使用一個被遺忘的，或者使用快捷鍵的高風險的測試。在那兒，不會有跟蹤我們的測試工作。不寫入日誌檔案，在整個測試期間，除非你增加這個你做的事情列表工作(手動)。
四、消極反饋迴圈
通常，當專案（因為某種原因）延期了，則容易陷入一種消極反饋迴圈。有時我們會先決定跳過編寫測試程式碼，而這則會造成情況如下圖所示：
專案延期，造成我們不得不去編寫更多的程式碼。所以與其“浪費時間”去不停地測試程式碼，不如不停地去開發專案。而這樣做的結果就是程式碼質量進一步下降，並最終（或早或晚）導致返工。返工又通常會在最有限的時間裡變得十分緊急（有些人叫這種現象為“墨菲是個樂天派！”）。其實返工什麼也改變不了，專案現在只會進一步被延遲。很奇怪吧，我們編寫越多的程式碼，我們的專案完工越晚。一種常用應對措施是讓更多的開發人員被參與到專案的研發中，然而這樣的作用也只是加劇消極反饋迴圈而已。
若專案缺乏測試，在驗收和生產環境時，通常使用者則會發現許多 bug，這將會快速地降低使用者對專案的信任度，從而產生消極反饋。這種反饋傳遞給（工作過度的）開發人員，就造成開發人員“疲勞”現象。後果就是開發人員工作積極性下降，開發人員離職，……，專案又進一步延遲了。
五、打破消極迴圈
我想你已經想到有一個辦法可以解決這種現象。讓我們來繪製一幅不同的場景：我們可以從一個理想計劃“專案按時完工”開始。我們開發程式碼，然後立即測試它。測試最好是自動化（編碼實現）的，這樣我們可以輕鬆有效的去執行它們。我們把開發和測試緊密的結合在一起，每個開發測試迴圈可以很快速的執行。當一個開發測試迴圈結束時我們有信心保證程式碼質量是很高的，因為它已經通過了測試。而且使用者因為發現缺陷（bug）的數目變少而對我們繼續高度信任。即使他們發現了一個缺陷（這依然是有可能的），我們也可以擴充我們的測試集合，去避免相關缺陷的重現。如此下去，返工將不再是必須的，專案得有繼續。如果我們的專案已經延期了，就需要我們花些時間來採用這種方法論。對新功能的凍結也許是必須的。停止開發新的程式碼，取而代之去為最嚴重的（惱人的－清晰的－高代價的）缺陷編寫測試。
專案延期的情況下再去為你完整的程式碼庫編寫測試是不可行的，只針對其中的一些部分就可以，不要去浪費你的時間。但是要記住其它部分也還是需要編寫測試的。我在這種情況下會去找出最嚴重的問題（劃分優先順序），然後為它們編寫測試。之後“快速”修改程式碼就會變的更容易，並且可以保證在修改其他部分是它不會出錯。自動化測試可以很頻繁的執行，從而降低了缺陷（bug）重現的風險。大講臺，最實用的 IT 職業線上學習平臺。好了，現在可以開始去有效的強健我們專案了
上面這些通常會要求進行程式碼重構，從而使它可測試化。我會在另一篇文章裡介紹它。
六、總結
大部分的專案中，會考慮測試和編碼之間的平衡。不過我希望大家都能清楚，測試其實是專案的加速器，而不是在浪費時間。
