整合測試關注各個 components 的功能性，也關注 components 之間的協同整合是否達到產品規格書上的預期。因為需要針對「不同 components 之間協同運作可能產生的影響」去思考，需要花更多時間去撰寫測試案例。且整合測試的複雜度與困難度相對單元測試高；測試覆蓋率卻相對單元測試低。聽起來吃力不討好，可是真的實踐出整合測試，能夠大幅提升產品的信心，因為你可以很有自信的跟使用者講說:「你看，產品規格書上的功能都沒有問題哦！」

要怎麼衡量一個產品需不需要寫整合測試呢？

• 時間
  首先考量「時間」，專案有沒有給予足夠的時間去設計、實踐整合測試？如果時間不夠，可能優先考量寫單元測試，或是僅挑選最有價值的整合測試案案例撰寫。
• 專案範疇
  再來的考量點是「專案範疇」，如果專案範疇小，或是專案 components 之間的耦合性不高，那麼撰寫整合測試的負擔會較小；反之，專案範疇大且 components 之間的協同運作程度高，就可想而知撰寫整合測試的成本會拉高。
• 錯誤修復成本及預期測試成效
  最後，可以考量「錯誤修復成本」及「希望測試能帶來的成效」，所謂「錯誤修復成本」是指「發現錯誤、排查錯誤、解決錯誤整個過程所需的時間成本」。專案如果希望「測試成效」可以著重在協助找出片段程式碼的微小 bugs，選擇單元測試可以快速除錯；若專案需要測試協助的部份在於測試 components 間的交互作用是否都能達到預期，那麼應該選擇整合測試。