recca chao 的 gitHub page

寫一些技術文件,筆記,雜七雜八

View on GitHub

原文摘錄自 http://blog.codepipes.com/testing/software-testing-antipatterns.html#anti-pattern-1—having-unit-tests-without-integration-tests

歡迎到原本部落格閱讀原文,認為翻譯有問題也歡迎討論。

僅有單元測試,沒有整合測試

這是中小型公司常有的問題。公司所開發的應用僅有單元測試(測試金字塔的最底層),缺乏其他部分。通常缺乏整合測試是因為以下原因:

第一點實在沒什麼好說的。任何有效率的團隊至少要有某位導師/領導人,讓其他人能參考較好的做法。第二點會在反模式

裡面進行詳細討論。

接著我們來到第三點:設置測試環境的困難度。別誤會,確實有一些應用的環境非常難部署。我曾經處理過一個 REST 應用,需要正式主機上特殊的硬體。這個硬體只有正式站上才存在,所以整合測試變得非常複雜,但這是特殊案例。

對一般公司所處理的普通網頁或者後端應用,設置測試環境不應該是個問題。現在有了docker 的 container 和各種虛擬環境,環境設置更不是問題。基本上,如果你的應用設置非常困難,你應該先修正你的設置程序,再來處理測試。

不過,為什麼整合測試這麼重要呢?

事實上,有一些問題是只有整合測試可以偵測出來的。最常見的範例是資料庫存取。資料庫交易(database transaction)、資料庫觸發程序(database trigger)以及任何的預存程序(stored procedure)只能透過整合測試操作並檢查。

除了資料庫存取外,任何連線至其他模組的操作,不管是自己開發或者其他團隊,都需要整合測試做驗證。任何檢查效能的測試也必定會是整合測試。

以下告訴我們為什麼需要整合測試:

問題種類 能以單元測試偵測 能以整合測試偵測
基本商業邏輯 可以 可以
元件整合問題 不可以 可以
資料庫交易 不可以 可以
資料庫觸發/預存程序 不可以 可以
與其他模組/API 訂定規格錯誤 不可以 可以
與其他系統訂定規格錯誤 不可以 可以
效能/逾時 不可以 可以
死鎖/活鎖 可能可以 可以
場景交換的安全問題 不可以 可以

基本上,所有應用的場景交換都需要整合測試進行偵測。在最近的微服務熱潮下,自己開發的服務與服務之間就會存在 API 資料交換,整合測試就變得更重要了。如果整個應用存在由其他團隊該發的服務,你必定需要某個自動化的方式來確定介面的規則沒有出錯,這只能由整合測試進行保障。

總之,除非你在建立某種非常特殊的應用,像是 linux 指令模式下的工具(utility),不然你需要整合測試來檢測出單元測試所無法察覺的問題。