100％代碼覆蓋率的悲劇

作者 | Daniel Lebrero

翻譯 | Aladdin

本文Daniel Lebrero在大數據團隊擔任IG的技術架構師。擁有超過15年的Java經驗和4年的Clojure經驗，他現在是函數式編程的大力倡導者。 以下為譯文：

有趣的是，我對測試的觀點正在發生變化。十五年來，我一直在推廣TDD（測試驅動開發，過去也被稱為測試優先方式），或至少對於開發者來說，寫一些單元測試。不過，最近我發現自己更常說：「你為什麼要寫測試？「而不是「你應該寫測試」。

到底是怎麼回事？

在辦公室周圍走走時，開發人員要求我幫助他進行單元測試。看來他在使用Mockito測試以下代碼時遇到了麻煩：

當我回應：「你不需要測試。」，他感到非常驚訝。

「但我不得不測啊！」 他說。「不測試我怎樣知道這段代碼能運行啊？」

「這段代碼的功能看起來很簡單，沒有條件，沒有循環，沒有轉換，沒有任何複雜的東西，只是一段簡單的老膠水代碼。

「但不測試的話，任何人都可以來更改這段代碼啊！」

「好，那我們試想來了個無知的開發者，試圖更改這些簡單的代碼，如果相關的單元測試發生了變化，他會做什麼，他只會刪除它。「

「但是如果你非要寫測試怎麼辦呢？」

「在這種情況下，我會這樣寫測試：」

「但是你沒有使用Mockito啊！」

「那又怎麼樣？Mockito在這種情況下不僅沒有幫助，恰恰相反：如果它順利運行了，還會使測試變得更複雜，更難讀懂。」

「但是我決定使用Mockito進行所有的測試！」

我： 」……」

下一次我碰到他，他自豪地說，他已經設法用Mockito寫了測試。我明白這個工作會讓他的心裡產生滿足感，但是他的解決方法還是讓我感到難過。

另一個例子

我被開發新應用程序的高代碼覆蓋率以及他們對BDD（行為驅動設計）的新發現所吸引。觀察代碼，我們發現以下Cucumber測試：

如果您以前使用過Cucumber測試 ，你就不會被支持代碼的數量驚訝到：

並且所有這些都需要測試：

是的，這只是一個簡單的map查找。我相信他，但還是直言不諱地說：「這是在浪費時間。」

「但我的老闆希望我能為所有的類寫測試，」他回答。

「代價是什麼？」

「費用？」

「不管怎麼說，這些測試與BDD無關。」

「我知道，但我們還是決定使用Cucumber進行所有測試。」

我： 「……」

我能理解按照自己的意志改造工具帶來的滿足感，但這種解決方案讓我感到難過。

悲劇在哪裡？

悲劇是，兩位聰明的開發人員（我們都要接受一個team interview）浪費時間寫這些測試，測試是毫無意義的，但這需要後來的IG開發人員來維護。

悲劇是，不用使用正確的工具，因為沒有什麼好的理由，我們決定不要用錯誤的工具。

悲劇是，一旦「所謂的好的做法」成為公司開發主流，我們似乎就會忘了這種做法的應用場景，它的優點是什麼，使用它的代價是什麼。

相應的，如果我們只是機械地應用它，不去思考它的原理，這通常意味著我們最終得到最平庸的結果，並且失去大部分的開發優勢，還要為此付出更大的代價。根據我的經驗，寫好的單元測試其實是項艱難的工作。

那麼100％的代碼覆蓋率是值得追求的嗎？

是的，每個人都應該在一個項目中實現。我認為你必須極端地去了解這麼做帶來的痛苦是什麼。

我們已經有了一個極端的經驗：開發有0個單元測試的項目，我們知道這樣做所帶來的痛苦。通常我們缺乏的是另一個極端的經驗：開發100％代碼覆蓋率和一切都是TDD的項目。單元測試（特別是第一種方法）是一個非常好的做法，但我們應該分辨哪些測試是有用的，哪些是適得其反的。

但記住沒有什麼工具使用起來是毫無代價的，沒有工具是萬能的，使用前請停下來想一想。

SDCC 2017·深圳站之架構&大數據技術實戰峰會將於2017年6月10-11日於深圳南山區中南海濱大酒店舉行，集阿里、騰訊、百度、滴滴出行、Intel、微博、唯品會的資深架構師和一線實踐者，納知名研發案例，遇見蘇寧雲商大數據中心總監陳敏敏、Apache RocketMQ聯合創始人馮嘉、餓了么大數據平台部總監畢洪宇等大牛。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！