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

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

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

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

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

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

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

開發工具很重要

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

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

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

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

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

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

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

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

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

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

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

來自: 外刊IT評論 http://www.aqee.net/