日期：2019年3月28日
編者注:本文原創發表在TechWell Agile Connection上．
這是很難爭議的測試金字塔是敏捷團隊的理想模型。單元測試為理解新代碼是否正常工作奠定了堅實的基礎:
- 它們實現了高代碼覆蓋率:編寫代碼的開發人員具有盡可能高效地覆蓋該代碼的唯一資格。負責任的開發人員很容易理解還沒有覆蓋的內容，並創建填補空白的測試方法。
- 它們又快又“便宜”:單元測試可以快速編寫，在幾秒鍾內執行，並且隻需要簡單的測試工具(相對於係統測試所需的更廣泛的測試環境)。
- 它們是決定性的:當單元測試失敗時，確定哪些代碼必須檢查和修複是相對容易的。這就像在一把幹草裏找一根針，而不是在一堆幹草堆裏找一根針。
然而，這個模型有一個問題:當你從進展來回歸測試．你的測試金字塔變成了菱形。
至少，這是我們最近在監視成熟敏捷團隊的單元測試實踐時收集到的數據。在每個衝刺階段，開發人員都非常認真地編寫驗證每個用戶故事所需的測試。通常，這是不可避免的:通過單元測試是“完成定義”的關鍵部分。在大多數sprint結束時，會有一個堅實的新單元測試基礎，這些測試對於確定新代碼是否正確實現並滿足預期至關重要。這些測試可以覆蓋大約70%的新代碼。
從下一個sprint開始，這些測試變成回歸測試。一點一點地，他們開始失敗-侵蝕的數量工作單元測試位於測試金字塔的底部，並侵蝕了測試套件曾經提供的風險覆蓋級別。在幾次迭代之後，曾經達到70%風險覆蓋率的相同單元測試隻提供原始功能的50%覆蓋率。在幾次迭代之後，這一比例下降到35%，並且在6個月之後通常下降到25%。
如果您無所畏懼地更改代碼，期望這些單元測試充當您的安全網，那麼這種微妙的侵蝕可能是極其危險的。
單元測試為什麼會腐蝕
單元測試受到侵蝕的原因有很多。即使單元測試理論上比其他類型的測試(例如，UI測試)更穩定，它們也不可避免地會隨著時間的推移開始失敗。隨著應用程序的發展，代碼將得到擴展、重構和修複。在很多情況下，實現的變化非常重要，足以保證單元測試的更新。其他時候，代碼更改暴露了原始測試方法和測試工具與技術實現耦合過於緊密的事實——同樣需要單元測試更新。
然而，這些更新並不總是進行的。在開發人員檢入一個新用戶描述的測試之後，他們就麵臨著獲取並完成另一個用戶描述的壓力。和另一個。和另一個。每一個新的用戶描述都需要通過單元測試才能被認為已經完成——但是如果“舊的”用戶描述開始失敗會發生什麼?通常,什麼都沒有。編寫該代碼的開發人員將繼續前進，因此他或她將需要重新熟悉被遺忘已久的代碼，診斷測試失敗的原因，並找出如何修複它。這不是小事，它可能會破壞當前衝刺的進展。
坦率地說，單元測試維護通常是許多開發人員真正厭惡的負擔。隻要掃一掃stackoverflow和類似的社區，就能找到無數開發人員在單元測試維護方麵的挫折。
如何穩定侵蝕
我知道一些特殊的組織需要—並為單元測試維護分配適當的資源。然而，這些組織往往擁有奢侈的sdet和專門用於測試的其他開發資源。許多企業已經在努力交付業務所期望的軟件數量和範圍，他們根本無法負擔將開發資源轉移到額外的測試上。
如果您的組織缺乏持續單元測試維護所需的開發資源，您可以做什麼?一種選擇是讓測試人員通過他們可以創建和控製的彈性測試來彌補損失的風險覆蓋。專業測試人員認識到，設計和維護測試是他們的主要工作，他們最終是由測試套件的成功和有效性來評估的。說實話吧。誰更有可能保持測試的最新狀態:迫於壓力而更快地交付更多代碼的開發人員，還是因發現主要問題而受到獎勵(或因忽視問題而受到指責)的測試人員?
在我們研究過的最成功的組織中，測試人員通過添加集成級測試來抵消侵蝕單元測試所造成的風險覆蓋損失——如果可行的話，主要是在API級。這使他們能夠恢複正在退化的“變更檢測安全網”，而不會中斷開發人員在當前衝刺中的進度。
日期：2019年3月28日
