一艘貨輪滿載著貨物從港口啟航，向浩瀚的大海深處破水而去。海面平靜，微微皺起波浪，從容而顯得寬容。然而，貨輪的步履卻有些蹣跚，發動機“轟轟轟”地嘶吼著，不堪重負，卻無法讓船只游得更快，倒像是海水咬住了船底往下在拖曳。

　　“嘟——嘟——嘟”，突然警報聲響起，甲板上變得喧鬧起來，一個水手模樣的年輕人聲嘶力竭地吶喊：“船超重了，快快快……快卸貨！”聲音急迫，甚至能聽到哭音。然后，又是一陣喧嚷，似乎是在爭吵甚么，就看到一個胖胖的中年人沖了出來。看他那肥胖的體型，真難想到他的身手竟然如此敏捷，如海豹一般破開人群，兩手揮舞，大聲喊道：“怎么了？怎么了？”，他停下來，吼道：“我看哪個不長眼的家伙敢卸我的貨！誰敢！”

　　船長走了過來，略帶恭敬地對那中年人說道：“老板，你看，這船超載了，船身吃緊，已經發出超重警報了。倘若不減輕船的重量，這船開不了多久就得沉了啊！”

　　“他奶奶的，這船可真秀氣啊！”中年人一邊罵罵咧咧，卻也知道形勢緊迫，容不得自己不下決斷。可是心里總存著僥幸心理，突然靈機一動，一把拉過船長，指著這艘貨輪問道：“既然這船超重，那我問你，除了貨物，這船上還有哪些東西占了船身的重量？”

　　船長一聽，立刻明白老板心里的小九九，沒好氣地回道：“除了貨物，占了這船重量的就還有人、淡水、食品，還有救生圈、救生衣、救生艇。老板你看那樣不順心，你就扔哪樣吧！”

　　嘿，回到現實中來吧。回答問題：倘若你是老板，你會扔哪樣呢？稍有理智的人，都不難做出正確的選擇。——然而，為何在軟件開發過程中，我卻常常看到有人選擇丟棄救生圈、救生衣、救生艇呢？哪怕它們的重量對于整艘船而言如同九牛一毛，卻總有人存著僥幸，認為船就超了那么一點點，或許扔出幾個救生圈，就能恢復重量到安全線；于是，貨物得以幸存，可以避免不必要的損失了。

　　或許，我們沒這么傻吧。那么，讓我們想想。

　　假設將這航行比作是軟件開發的過程，那么載貨到達目的地，就是實現軟件需求。只有交付了貨物，才算是實現了價值。至于淡水、食品以及船只，就是開發的工具與環境，而救生圈、救生衣、救生艇，就是我們在開發過程中需要編寫的自動化測試（單元測試、集成測試、驗收測試等）。我們需要這些測試來隨時檢測開發功能是否有誤，及時反饋，就像在航行過程中，若是有人溺水，可以用救生衣、救生圈挽回一條生命一般。

　　可一旦開發時間緊促，人手嚴重不足，進度壓力山大時，我們想到了什么呢？對于我見過的多數軟件團隊而言，每當面臨如此窘境時，首先想到的就是減少甚至不做自動化測試。有人認為自動化測試沒有價值，浪費成本；有人認為自動化測試可以以后再補，先把功能完成再說；有人認為有了手動測試，就足以保障項目的質量……如此這般，自動化測試就這般被忽略了，淪落到隨時可以拋棄的地位。

　　倘若軟件開發就只有這一個階段，沒有需求變更，沒有后續開發，沒有軟件維護。項目的代碼庫如樹苗一般在陽光雨露下茁壯成長，沒有大風狂吹，沒有烈日暴曬，沒有大雨傾盆，亦沒有蟲蟻啃嚙，那自然由得它去。然而，現實世界哪有如此美好！

　　Michael Feather 將沒有自動化測試的代碼稱為“遺留代碼”，溫伯格在《咨詢的奧秘》中則認為應該將“維護”工作視為“設計”工作。自動化測試是修改的基礎，重構的保障，設計的規約，演化的文檔。它的重要性怎么強調都不過分，然而很可惜，在很多軟件項目開發中，它甚至不如“雞肋”的地位，說放棄就放棄了，在決定當時，毫不覺得可惜。至于以后的以后，不遠的未來，誰還顧得上！！？債欠下了，什么時候償還呢？——不知道！到了催債的那天，再想辦法還債吧。

　　鴕鳥心態害死人啊！

　　捫心自問，我們經歷過維護的苦楚嗎？體驗過修改代碼的煩惱嗎？修復過不勝其擾的缺陷嗎？答案若是肯定，那么，如果老天再給你一次機會，把選擇自動化測試的權利放在你面前，作為“曾經滄海難為水”的你，你會怎么選？——所以，我想問問程序員們：今天，你寫自動化測試了嗎？