一個新手為老程式碼寫測試程式的心得

　　我堅持去健身房鍛鍊身體，練習舉重，我喜歡這種讓自己變得更強壯、更健康的感覺。大約兩個月前，我的膝蓋開始感覺抽痛，但我仍然堅強去鍛鍊。

　　我一心想讓自己更強壯，完全忽視了腿上的健康問題，仍然強迫自己繼續舉重。你可以想象出，膝蓋上的痛沒有好轉，每一次精疲力盡的鍛鍊後我都需要更長時間的恢復。

　　作為一個在Rackspace公司的初級程式設計師(在Airbrake開發組)，我經常會有一種相似的感覺，它催促我不停的大量產出程式碼，以為這樣能讓產品更強壯。當正如我的膝蓋每次在下蹲時都要忍受痛苦一樣，未經測試的老的功能特徵在大量出現的新功能的重壓下開始變形，開始斷裂。

　　最終我的物理治療師說服我應該重點做康復鍛鍊，恢復前不要再去舉重。他說，當膝蓋上的問題好了之後，肌肉變得更結實有力後，我的進步會更快，也更不容易弄傷自己，讓自己痛苦。

　　銘記了這些忠告，我看到了它和工作之間的聯絡。我強迫自己去給老程式碼、老功能寫測試程式碼，這樣使得我的開發進度更快，對程式碼更有信心，不再擔心開發新程式碼時會破壞老程式碼的功能。

　　下面是我在這個轉變過程中學到的關鍵幾點：

　　開發工具很重要

　　我使用RSpec, Capybara, FactoryGirl 和 Selenium 來測試我的Rails應用。在寫測試程式碼之前，你要先研究一下這些工具。否則，除錯這些測試程式碼浪費你大量的時間。

　　一些簡單的任務，例如在測試前和測試後清除資料庫，它們對保證你能正確的、快速的、可重複的測試起著重要作用。對於這些任務，你可以使用這個database_cleaner gem。

　　如果你是團隊中第一個來寫測試程式碼的人，這個時候測試工具的選擇尤其重要，它會影響團隊其他成員對測試的接受。整個團隊都要提交測試程式，所以你要讓這個過程儘可能的簡單，——採用強大、靈活的工具。

　　現有的程式碼只是告訴你現在做成了什麼樣，但不是告訴你程式碼實際應該是這樣。

　　當開始測試別人的程式碼時，我發現有個習慣，首先假設這些程式碼是正確的，符合要求的，所以這些程式碼中能夠通過測試用例。有時這樣是沒問題的，但有時這些程式碼之所以通過測試只是因為測試程式碼是按照它們寫的。

　　你忍不住會圖省事，會假設所有的這些程式碼是最新的，符合要求的，然後寫的測試來證實這些假設。這就導致了一種反向的測試驅動開發模式：程式碼成了測試的依據和標準。

　　安全的做法是探求程式碼最初的意願，資深的程式設計師更喜歡寫出很明晰的程式碼，你能通過程式碼看出它試圖實現的功能。

　　完全測試是不可能的，不要這樣要求自己

　　為整個專案寫測試程式，你可能需要將它當作一種全職工作來對待。當然，我們都希望100%(+)的測試覆蓋率，就像我們都希望洗滌盆裡沒有髒盤子。然而，另外一種方法是當你需要盤子時清洗所需的盤子。我們用這種策略為新程式碼寫測試程式，老程式碼中我們開發的過程中遇到時再寫測試程式。

　　我建議新程式設計師應該去為老程式寫測試，這樣它能強迫你學習老程式碼庫，讓你獲得更深的肌肉記憶力。但一定要遵循上面的這些原則。

　　英文原文：What I Learned as a Junior Developer Writing Tests for Legacy Code