在 1998 年，Kent Beck 編寫了 sUnit，一個面向 SmallTalk 的單元測試框架。之后，他將這個框架移植到 JAVA，即 jUnit。從那時起，xUnit 框架擴展到那些最流行的編程語言。比較新的語言，如 Golang 和 Rust，已經將測試直接合并到編譯器和標準庫中。

但是單元測試并不是唯一。還有集成測試和性能測試等等。在我看來，集成測試和單元測試是健壯軟件的基石。因此，今天讓我們看看單元測試與集成測試之間的區別，以及你什么時候該選擇哪種測試。

什么是一個單元？

一個單元是邏輯上分離的最小代碼塊

單元測試是一種孤立地測試盡可能小的代碼片段的測試。那么，什么是一個單元？

術語“單元”來自數學。數字 1 被認為是單元，因為它是最小的自然數。它是最小的正整數。以此類推，你源代碼的一個單元就是邏輯上與其余代碼分離的最小代碼片段。它是一個完整的且邏輯上不同的代碼片段，而且是最小的部分。

在大多數編程語言中，你的單元會是一個函數或方法調用。

單元測試的好處是，如果你的代碼由獨立的小片段組成，那么，為它們編寫測試就相當容易。這種易編寫性意味著你可以在開發功能時完成單元測試。

與其它形式的測試相比，單元測試的執行時間相當短。這意味著你可以頻繁運行單元測試。隨著軟件的成熟，一套單元測試是防止回歸和降低維護成本的有力工具。

追溯單元測試

在考慮將單元測試添加到現有軟件時，需要考慮成本和收益。

單元測試的一個關鍵假設是，被測試的軟件很容易分成不同的單元。在沒有考慮單元測試編寫的軟件中，這個假設很少成立。向現有軟件添加單元測試通常是一種非常好的方法，來穩定軟件并防止將來回歸，但是重構代碼來支持簡單的單元測試可能需要大量工作，甚至會引入新的缺陷。在考慮將單元測試添加到現有軟件時，需要考慮成本和收益。如果你的代碼正在工作，如果代碼很少需要修改，如果代碼不容易進行單元測試，那么加入單元測試的好處可能無法保證成本。在這些情況下，可以依靠集成測試來防止該領域的缺陷。

什么是集成測試?

集成測試聚焦于整個軟件棧

如果單元測試的哲學是基于這樣一種認識，即測試小的獨立代碼片段是防止回歸的一種好方法，那么集成測試是基于這樣一種理解，即事情通常在邊緣狀態出錯。外部世界是一個混亂的地方，它與你代碼交互的地方通常是意外發生的地方。

你可以通過單元測試實現 100%代碼覆蓋率，但仍然發現你的軟件失敗。你可能試圖從錯誤的位置讀取文件，或者你的軟件可能從一個調用的服務得到預期之外的輸出，或者它可能以一種無效的方式調用數據庫。

盡管單元測試應該快速運行并且數量眾多，但是一個好的集成測試策略應該關注較少數量的高影響測試。

這些測試應該跨越單元測試無法跨越的所有界限，寫入文件系統，接觸外部資源，等等。

當集成測試棘手時

某些外部系統確實很難集成到測試中。這是因為它們在現實世界中有著無法消除的副作用：金融交易、電子郵件發送、物理移動一個噴漆機器人等。在你在測試中放棄并避開它們之前，找找解決方案。

許多外部系統有一個文檔化的方法來在集成測試中使用它們。支付處理程序通常有測試信用卡號，可以設置具有測試郵箱賬戶的測試用戶來測試郵件發送。

集成測試越接近真實世界的交互，就越有可能發現問題并提供真正的價值。

Amazon SES——Test email addresses

Paypal——Test credit card numbers

UPS——Test api mode

一個電子商務例子

假設你正在編寫一個簡單的電商網站，一個簡化版的 amazon.com。這里的細節很重要，所以我們假設，你會使用 PostgreSQL 作為你的數據存儲，使用 PayPal 進行支付，使用 UPS 進行發貨、使用 Amazon Simple Email Service 來發送電子發票郵件。

單元測試：

單元測試策略將以一種孤立的方式測試應用程序的邏輯。這可能包括：

• 測試稅費計算邏輯是否正確地計算出各個司法管轄區的稅費
• 測試放置到購物車數據結構中的項目是否被正確添加
• 測試折扣代碼是否被正確使用

這些領域中的每一個都可能有幾個測試。每個測試將驗證一小部分功能。單元測試的能力來自它們的數量、簡單性以及它們的執行速度和便捷性。

集成測試：

另一方面，你的集成測試將專注于測試你的電子商務代碼與其它系統的交互。這意味著不僅要測試與數據存儲的集成，還要測試與郵件發送服務的集成、與支付服務的集成等等。這些可能包括：

• 測試是否可以從外部運輸服務中檢索運輸費率
• 測試發票是否可以生成并正確發送
• 測試訂單信息是否可以持久化并從數據存儲中正確檢索
• 測試交易是否可以發送并被支付處理程序正確處理

這些功能中的每一個都可能需要一個或兩個集成測試來驗證。這些測試運行起來會比較慢，可能涉及一些安裝和拆卸步驟。結果是，每個測試的代碼覆蓋率會相當大。這些測試將通過捕獲單元測試不能捕獲的問題來產生價值。然而，維護成本和執行時間可能會比較高。

集成測試 vs 單元測試

是時候正面比較了

那么，應該首選哪種類型的測試呢？單靠兩者中的任一個都是不夠的。這兩者都是綜合測試計劃的一部分。讓我們直接比較一下：

基于理想化測試的工作軟件

每種情況都是獨特的，基于在其它情況下有效的建議不應盲目遵循。

現在我們明白了，單元測試不應該觸及文件系統，而集成測試應該只集成松散的組件。但實際上，將測試劃分為兩個明確的類別有點太簡單了，如果我們只關注定義，我們就會忽略目標，即正確的工作軟件。

一些非常有想法的開發者認為單元測試可以并且應該讀寫數據庫。其它人則認為單元測試是一種浪費，粗粒度的集成測試提供的價值最大。

問題是，每種情況都是獨特的，基于在其它情況下有效的建議不應盲目遵循。需要牢記的一個問題是，這個測試要捕獲什么類型的缺陷。如果每個測試都是經過深思熟慮編寫來提升軟件可靠性的，如果測試在不再有價值時被刪除，那么隨著時間的推移，將發現為特定項目提供最大價值的特定測試方法。

原文鏈接：

https://blog.earthly.dev/unit-vs-integration/