從測試驅動開發和生產環境測試中獲得反饋

作者 | Ben Linders

譯者 | 劉雅夢

Ola Hast 和 Asgaut Mj?lne S?derbom 在他們在倫敦 QCon關于結對編程的持續交付的演講中提到，團隊依賴于強大的單元測試和集成測試，而不是端到端的測試。使用 TDD（測試驅動開發）、結對編程和良好的設計，他們經常發布小的更改，在生產環境中測試真實的反饋，并使用功能開關來降低風險。

Hast 提到，他們信任他們的單元測試和集成測試，并且把它們作為一個整體。他們沒有端到端測試：

我們通過使用良好的關注點分離、模塊化、抽象、低耦合和高內聚來實現這一點。這些機制與 TDD 和結對編程相輔相成。結果是一個具有高代碼質量的更好的領域驅動設計。

以前，他們有更多的 HTTP 應用程序集成測試，測試整個應用程序，但他們已經從這個（或只有一些愉快的案例）轉向了更專注的測試，這些測試有更短的反饋循環，Hast 提到。

由于測試環境總是近似生產環境，并且通常與長供應鏈和糟糕的測試數據作斗爭，他們或多或少已經停止使用它們了，Mj?lne S?derbom 解釋說：

我們更喜歡在生產環境中測試，因為在那里我們可以得到最高質量的反饋。

他們通過將新功能放在開關后面，并一次部署一小部分來降低風險。這是他們已經做了好幾年的事情，而且效果非常好，Mj?lne S?derbom 說。如果生產環境中出現故障，很容易找到、修復和回滾 / 前進，他補充說。

在之前的文章中，Hast 和 Mj?lne S?derbom 提到他們的團隊 使用 TDD 進行結對和 mob 編程；沒有單獨的任務或單獨的代碼審查。這種方法提高了代碼質量，減少了浪費，并促進了知識的共享：

經過多年的實踐，我們最終一起工作，進行 TDD，然后部署到生產環境。我們很少在本地或測試環境中測試應用程序。這從來不是我們的主要意圖；這只是我們工作方式的一個（愉快的）結果。

結對編程和持續集成可以相輔相成。每天多次向主服務器推送是很困難的，這會導致延遲、大型 PR 和合并問題。結對使即時代碼審查、更容易的重構、更少的錯誤和更高的團隊韌性成為可能，Hast 和 Mj?lne S?derbom 解釋說。

Hast 提到他們過去有更多的測試，測試整個應用程序的運行，但他們已經將這個減少到最低；他們通常只有一條愉快的路徑測試，以及針對任何特殊錯誤情況的額外測試：

我們不能用單元測試中測試的東西，我們更喜歡在生產環境中測試。測試總是現實的近似，我們總是與長供應鏈和糟糕的測試數據作斗爭。我們總是從生產環境中得到最好的反饋。停止使用測試環境本身從來不是一個目標，但它只是另一個令人愉快的副作用。

最重要的是建立反饋循環，Mj?lne S?derbom 提到。反饋有助于導航和選擇方向，必要時改變方向：

我們從我們的測試中得到最快的反饋，從生產環境中得到最好的反饋。

當某件事情很痛苦時，他們會更頻繁地這樣做，Hast 解釋說：

我們公司今天之所以能走到這一步，是因為我們增加了部署到生產環境的頻率，并在問題最嚴重的地方迅速得到反饋，然后修復了這些問題。這個過程已經持續了 10 年。

我們非常專注于開發過程中所有級別的快速反饋循環，Mj?lne S?derbom 說。TDD 是我們獲得早期和快速反饋的最重要的工具之一，他解釋說：

如果你的代碼難以測試，通常意味著設計有問題。代碼與我們“對話”，并驅動設計。

許多人認為 TDD 是一個測試工具，但實際上，它是一個設計工具。Mj?lne S?derbom 總結說，擁有適當的測試來實現快速流動是一個（非常好的）副作用。

https://www.infoq.com/news/2026/02/feedback-TDD-production/