Google測試工程師日常工作：構建基礎設施才是重點(2)

幾年前，我加入了一個工程項目組，主要任務是開發一個新系統替換舊系統。因為構建替換過程需要幾年，我們需要保持舊系統正常運行，甚至在舊系統上添加新功能，同時慢慢替換為新系統，這樣才不會影響用戶使用。

然而舊的系統是如此復雜和脆弱，工程師要花費大部分時間來分類并修復 bug 及進行相關測試，以至于沒有時間實現新系統。新系統的目標是實現所有老系統功能的基礎上，并使之更容易維護且擴展性更好。作為團隊的 TE，我的工作是了解高維護成本的成因及如何改進。

我發現兩個主要問題：

• 緊耦合和抽象不足使得單元測試非常困難，因此，需要大量的端到端功能測試來驗證所有的代碼。

• 端到端測試的基礎設施沒有機制提供創建和注入 mock 服務的方法。因此，測試必須為所有這些外部依賴關系啟動大量服務器。這導致了測試的工作量很大并且很脆弱，現有的基礎設施無法可靠地處理這一問題。

解決方案

首先，我嘗試將大測試分成更小的測試的可能性，小測試可以聚焦特定幾個功能，并減少依賴服務的數量。但是，在結構不良的舊系統代碼中，發現這個想法是不可能的，如果要按這種方法工作將需要重構整個系統及其依賴項，這不僅僅是測試團隊可以完成的工作。

第二種方法，我嘗試進行大的測試，并試圖將非測試的功能的調用進行 mock。這最終證明也是非常困難的，因為依賴經常改變，并且單個依賴很難在 200 多個服務中進行追蹤。最終，這種方法只是將所需的工作從維護測試代碼轉移到模擬和維護測試依賴。

我的第三個也是最后一個方法，如下圖所示：使小測試用例更加強大。在我們面臨的典型的端到端測試中，客戶端對幾個服務進行了 RPC 調用，這些服務又 RPC 調用了其他依賴服務?？蛻舳撕退泻蠖朔盏恼{用閉包一起形成了一個大的依賴圖（而不是樹?。?，這一切都必須在端到端測試中運行。

新模型改變了我們如何對客戶端和服務端進行測試，僅運行客戶端來執行幾個 RPC 調用，然后觀察相關依賴調用是否正常的做法不太適合，我們對 RPC stub 的代碼編寫單元測試，Stub 本身是用一個常見的模擬框架（如 Java 中的 Mockito）來完成的。

原文轉自：https://www.testwo.com/article/891