測試癌症

隨著我的職業生涯轉為全職寫作，我經常擔心自己會與日常軟體開發的現實脫節。我見過其他知名人物失去與現實的聯繫，我害怕自己也會步上後塵。我對抗這種情況的最大助力是 Thoughtworks，它就像一劑定期的現實良藥，讓我腳踏實地。

Thoughtworks 也是來自現場的靈感來源，我很喜歡撰寫同事發現和開發的有用事物。這些通常是有用的點子，我希望我的部分讀者能夠使用。我今天的題目並不是這麼令人愉快的題目。這是一個問題，而且我們沒有答案。

情境如下。我們為客戶執行一個專案，並交付一個閃亮的新軟體。就像我們現在的習慣，我們也為這個軟體交付一批自動化測試（通常測試程式碼行數與功能程式碼行數一樣多）。這些測試通常是單元測試和範圍較廣的功能與驗收測試的組合。無論如何，這些測試都是軟體功能的積極描述，也是在我們開發軟體時快速找出問題的錯誤偵測器。我們珍視這些測試，它們是我們建構軟體系統成功的關鍵。

幾個月後，滿意的客戶回頭找我們，希望在軟體上做一些進一步的工作，新增一些新功能和能力。我們進來，熱切地想處理一個可能有些錯誤的程式碼庫，但至少是我們的錯誤。然後我們發現了一個令人不快的問題。

測試不再執行。

有時，測試會從建置腳本中排除，並且幾個月來都沒有執行。有時會執行「測試」，但其中很大一部分都被註解掉了。無論哪種方式，我們寶貴的測試都受到一種討厭的癌症侵襲，這種癌症既耗時又令人沮喪。

我們詢問發生了什麼事，得到的回答像是「我們做了一個變更，導致一些測試中斷，所以我們移除了這些測試」。你可以將此視為我們的失敗——我們未能完全教導客戶團隊測試的價值。我們需要做更多努力，傳達失敗的測試需要調查，而不是簡單地忽略。但無論任何人說什麼，我們都發現測試的癌症是一種常見的疾病。

我們不認為測試癌症出現的事實是反對撰寫測試的理由。即使在我們離開後的那天，一種特別毒的菌株將它們全部消滅，我們仍然從它們身上獲得價值，因為我們正在建置系統。而且測試並非總是會得癌症。我們最近與一位開發人員交談，他在維護我們幾年前移交的系統後，成為了 TDD 的信徒。與其他公司後來新增的程式碼相比，測試使我們的程式碼更容易使用。