僅有單元測試，沒有整合測試
歡迎到原本部落格閱讀原文，認為翻譯有問題也歡迎討論。
這是中小型公司常有的問題。公司所開發的應用僅有單元測試（測試金字塔的最底層），缺乏其他部分。通常缺乏整合測試是因為以下原因：
- 公司缺乏資深工程師。整個團隊只有較資淺的工程師，他們只看過單元測試。
- 整合測試曾經存在，但是因為製造太多問題所以被放棄了。單元測試相較之下更容易維護所以保留下來。
- 環境設置非常「有挑戰性」，所以所有功能都在正式站上「測試」。
第一點實在沒什麼好說的。任何有效率的團隊至少要有某位導師/領導人，讓其他人能參考較好的做法。第二點會在反模式
- 測試內部實作
- 離譜或緩慢的測試
- 手動測試
裡面進行詳細討論。
接著我們來到第三點：設置測試環境的困難度。別誤會，確實有一些應用的環境非常難部署。我曾經處理過一個 REST 應用，需要正式主機上特殊的硬體。這個硬體只有正式站上才存在，所以整合測試變得非常複雜，但這是特殊案例。
對一般公司所處理的普通網頁或者後端應用，設置測試環境不應該是個問題。現在有了docker 的 container 和各種虛擬環境，環境設置更不是問題。基本上，如果你的應用設置非常困難，你應該先修正你的設置程序，再來處理測試。
不過，為什麼整合測試這麼重要呢？
事實上，有一些問題是只有整合測試可以偵測出來的。最常見的範例是資料庫存取。資料庫交易（database transaction）、資料庫觸發程序（database trigger）以及任何的預存程序（stored procedure）只能透過整合測試操作並檢查。
除了資料庫存取外，任何連線至其他模組的操作，不管是自己開發或者其他團隊，都需要整合測試做驗證。任何檢查效能的測試也必定會是整合測試。
以下告訴我們為什麼需要整合測試：
| 問題種類 | 能以單元測試偵測 | 能以整合測試偵測 |
|---|---|---|
| 基本商業邏輯 | 可以 | 可以 |
| 元件整合問題 | 不可以 | 可以 |
| 資料庫交易 | 不可以 | 可以 |
| 資料庫觸發/預存程序 | 不可以 | 可以 |
| 與其他模組/API 訂定規格錯誤 | 不可以 | 可以 |
| 與其他系統訂定規格錯誤 | 不可以 | 可以 |
| 效能/逾時 | 不可以 | 可以 |
| 死鎖/活鎖 | 可能可以 | 可以 |
| 場景交換的安全問題 | 不可以 | 可以 |
基本上，所有應用的場景交換都需要整合測試進行偵測。在最近的微服務熱潮下，自己開發的服務與服務之間就會存在 API 資料交換，整合測試就變得更重要了。如果整個應用存在由其他團隊該發的服務，你必定需要某個自動化的方式來確定介面的規則沒有出錯，這只能由整合測試進行保障。
總之，除非你在建立某種非常特殊的應用，像是 linux 指令模式下的工具（utility），不然你需要整合測試來檢測出單元測試所無法察覺的問題。