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

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

什么是一個單元？

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

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

術(shù)語“單元”來自數(shù)學(xué)。數(shù)字 1 被認(rèn)為是單元，因?yàn)樗亲钚〉淖匀粩?shù)。它是最小的正整數(shù)。以此類推，你源代碼的一個單元就是邏輯上與其余代碼分離的最小代碼片段。它是一個完整的且邏輯上不同的代碼片段，而且是最小的部分。

在大多數(shù)編程語言中，你的單元會是一個函數(shù)或方法調(diào)用。

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

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

追溯單元測試

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

單元測試的一個關(guān)鍵假設(shè)是，被測試的軟件很容易分成不同的單元。在沒有考慮單元測試編寫的軟件中，這個假設(shè)很少成立。向現(xiàn)有軟件添加單元測試通常是一種非常好的方法，來穩(wěn)定軟件并防止將來回歸，但是重構(gòu)代碼來支持簡單的單元測試可能需要大量工作，甚至?xí)胄碌娜毕荨Ｔ诳紤]將單元測試添加到現(xiàn)有軟件時，需要考慮成本和收益。如果你的代碼正在工作，如果代碼很少需要修改，如果代碼不容易進(jìn)行單元測試，那么加入單元測試的好處可能無法保證成本。在這些情況下，可以依靠集成測試來防止該領(lǐng)域的缺陷。

什么是集成測試?

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

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

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

盡管單元測試應(yīng)該快速運(yùn)行并且數(shù)量眾多，但是一個好的集成測試策略應(yīng)該關(guān)注較少數(shù)量的高影響測試。

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

當(dāng)集成測試棘手時

某些外部系統(tǒng)確實(shí)很難集成到測試中。這是因?yàn)樗鼈冊诂F(xiàn)實(shí)世界中有著無法消除的副作用：金融交易、電子郵件發(fā)送、物理移動一個噴漆機(jī)器人等。在你在測試中放棄并避開它們之前，找找解決方案。

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

集成測試越接近真實(shí)世界的交互，就越有可能發(fā)現(xiàn)問題并提供真正的價值。

Amazon SES——Test email addresses

Paypal——Test credit card numbers

UPS——Test api mode

一個電子商務(wù)例子

假設(shè)你正在編寫一個簡單的電商網(wǎng)站，一個簡化版的 amazon.com。這里的細(xì)節(jié)很重要，所以我們假設(shè)，你會使用 PostgreSQL 作為你的數(shù)據(jù)存儲，使用 PayPal 進(jìn)行支付，使用 UPS 進(jìn)行發(fā)貨、使用 Amazon Simple Email Service 來發(fā)送電子發(fā)票郵件。

單元測試：

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

測試稅費(fèi)計(jì)算邏輯是否正確地計(jì)算出各個司法管轄區(qū)的稅費(fèi)
測試放置到購物車數(shù)據(jù)結(jié)構(gòu)中的項(xiàng)目是否被正確添加
測試折扣代碼是否被正確使用

這些領(lǐng)域中的每一個都可能有幾個測試。每個測試將驗(yàn)證一小部分功能。單元測試的能力來自它們的數(shù)量、簡單性以及它們的執(zhí)行速度和便捷性。

集成測試：

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

測試是否可以從外部運(yùn)輸服務(wù)中檢索運(yùn)輸費(fèi)率
測試發(fā)票是否可以生成并正確發(fā)送
測試訂單信息是否可以持久化并從數(shù)據(jù)存儲中正確檢索
測試交易是否可以發(fā)送并被支付處理程序正確處理

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

集成測試 vs 單元測試

是時候正面比較了

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

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

每種情況都是獨(dú)特的，基于在其它情況下有效的建議不應(yīng)盲目遵循。

現(xiàn)在我們明白了，單元測試不應(yīng)該觸及文件系統(tǒng)，而集成測試應(yīng)該只集成松散的組件。但實(shí)際上，將測試劃分為兩個明確的類別有點(diǎn)太簡單了，如果我們只關(guān)注定義，我們就會忽略目標(biāo)，即正確的工作軟件。

一些非常有想法的開發(fā)者認(rèn)為單元測試可以并且應(yīng)該讀寫數(shù)據(jù)庫。其它人則認(rèn)為單元測試是一種浪費(fèi)，粗粒度的集成測試提供的價值最大。

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

原文鏈接：

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