整合測試

整合測試用於確定獨立開發的軟體單元在連接彼此時是否能正確運作。這個術語即使在軟體產業的模糊標準中也變得模糊不清，因此我一直在我的寫作中避免使用它。特別是，許多人假設整合測試的範圍必然廣泛，而實際上範圍較窄的整合測試可以更有效地執行。

對於這些事情，通常最好從一點歷史開始。我第一次瞭解整合測試時，是在 1980 年代，而瀑布模型是軟體開發思維的主流。在一個較大的專案中，我們會有設計階段，用於指定系統中各種模組的介面和行為。然後會將模組分配給開發人員進行編寫程式。一個程式設計師負責一個單一模組並不少見，但這個模組可能很大，需要花費數個月才能建置完成。所有這些工作都是獨立完成的，當程式設計師認為它已經完成時，他們會將它交給 QA 進行測試。

測試的第一部分是單元測試，它會針對模組本身進行測試，並根據設計階段完成的規格進行測試。一旦完成，我們就會進行整合測試，將各種模組組合在一起，形成整個系統或重要的子系統。

顧名思義，整合測試的重點在於測試許多獨立開發的模組是否能如預期般一起運作。它透過啟用許多模組，並針對所有模組執行較高層級的測試來執行，以確保它們能一起運作。這些模組可以是單一可執行檔的一部分，也可以是獨立的。

從 2010 年代的角度來看，這些混淆了兩件事

• 測試獨立開發的模組是否能正確地一起運作
• 測試由多個模組組成的系統是否能如預期般運作。

這兩件事很容易混淆，畢竟，如果不將購物車和目錄模組都啟用到單一環境中，並執行同時使用這兩個模組的測試，你還能如何測試它們呢？

2010 年代的觀點提供了另一種選擇，這在 1980 年代鮮少被考慮。在另一種選擇中，我們透過執行購物車中與目錄互動的程式碼部分來測試購物車和目錄模組的整合，並針對目錄的 TestDouble 執行。如果測試雙替身是目錄的忠實雙替身，我們就可以在不啟動完整目錄實例的情況下測試目錄的所有互動行為。如果它們是單體應用程式的獨立模組，這可能不是什麼大問題，但如果目錄是獨立服務，需要自己的建置工具、環境和網路連線，那就會是很大的問題。對於服務，此類測試可以在處理中測試雙替身，或使用類似 mountebank 的東西針對有線雙替身進行測試

針對雙替身進行整合測試時，一個顯而易見的陷阱是該雙替身是否真正忠實。但我們可以使用 ContractTests 另外測試這一點。

透過使用這項結合窄整合測試和合約測試，我可以確信在不針對該服務的實際實例執行測試的情況下整合外部服務，這大幅簡化了我的建置流程。執行此操作的團隊可能仍會對所有實際服務執行某種形式的端對端系統測試，但如果是這樣，那只會是針對範圍非常有限的路徑執行的最後煙霧測試。這也有助於具備成熟的 生產中的 QA 能力，而且如果夠成熟，甚至可能完全不執行端對端系統測試。

問題在於我們（至少）有兩種不同的觀念，構成整合測試。

窄整合測試

• 僅執行服務中與獨立服務對話的程式碼部分
• 使用這些服務的測試雙替身，無論是處理中或遠端
• 因此包含許多範圍狹窄的測試，範圍通常不比單元測試大（而且通常與用於單元測試的相同測試架構一起執行）

廣泛整合測試

• 需要所有服務的實況版本，需要大量的測試環境和網路存取
• 執行所有服務的程式碼路徑，而不仅仅是負責互動的程式碼

而且有大量的軟體開發人員，對他們來說「整合測試」只表示「廣泛的整合測試」，當他們遇到使用狹義方法的人時，就會產生許多混淆。

如果你的整合測試只有廣泛的測試，你應該考慮探索狹義的風格，因為它可能會顯著改善你的測試速度、易用性和復原力。由於狹義的整合測試範圍有限，因此它們通常執行得非常快，因此可以在部署管線的早期階段執行，如果它們變為紅色，則可以提供更快的回饋。

好像這個術語混淆還不夠，在 2010 年代後期，事情變得更糟，出現了「整合測試」的另一種用法。這是因為單元測試的意義出現分歧。有些人定義單元測試為我所指的單獨單元測試，其中除了受測單元之外的所有程式元素都用測試替身取代。根據這個狹義的定義，一些作者定義「整合測試」是指社交單元測試。

這就是我對「整合測試」感到謹慎的原因。當我讀到它時，我會尋找更多背景資訊，這樣我才知道作者真正指的是哪種類型。如果我談論廣泛的整合測試，我比較喜歡使用「系統測試」或「端到端測試」。對於狹義的整合測試，我沒有更好的名稱，所以我確實使用了那個名稱（但加上「狹義」來幫助讀者了解這些測試的性質）。我繼續對兩種測試都使用「單元測試」，在需要區分時使用單獨/社交。