InfoQ China刊了J.B. Rainsberger的一篇文章題爲
J.B. Rainsberger：“集成測試是個陰謀”
J.B.對集成測試作了定義，認爲集成測試是
簡單可以理解爲集成測試是依賴於其他（多於一個）測試的測試。
J.B.爲什麼認爲集成測試是一個因爲，他的觀點是：
1.開發人員認爲某一缺陷只能通過集成測試發現，因此認爲應該integrate everywhere，要寫大量集成測試。
2.J.B.列舉一箇中型web app的集成測試大概包含至少1000個集成測試，開發人員容易產生牴觸情緒。
3.J.B.以兩個測試進行對比，一個是對象測試（我的理解是單元測試），另一個則是集成測試，對象測試花費6秒，集成測試花費1分鐘，而開發人員保持1分鐘屏幕關注時間是不可能的，一分鐘當中開發人員的注意力分散從而導致過多開銷和低效，J.B.稱之爲集成測試的“隱含成本”。
關於觀點1，根據我的測試經歷，集成測試的目標應該關注於“集成可運行”上，比如一個集成涉及BO1, BO2,那麼集成測試關注的應該是BO1+BO2得到的測試結果是可信的，而且測試結果通常不涉及太多可能性測試，比如通過不同的入口來測試集成結果的準確性，這樣成本的確很高，而且會跟BO1，BO2的單元測試產生重疊，這也是一些集成測試採用MOCK測試的原因。
關於觀點2，如果集成測試採用我說的那種“通過不同的入口來測試集成結果的準確性”的話，的確會發生牴觸情況，因爲集成測試的測試周期相對較長，內聚性不強，需要耗費很多精力，比如有可能涉及很多條件分支。
關於觀點3，J.B.這裏是拿集成測試和單元測試做比較，固然這是一個視角，但是這個視角是否全面我認爲有失偏頗，拿一個JavaWebApp作例，對Service類做測試比較容易，如果把Action看作集成測試的話，Action測試的難度要較前者高，因而往往Action的測試有可能會被忽略掉，但是問題的發生在手工調試Action這一環節，比如出現Service中出現空指針，如果對Action做測試的話，問題有可能會在測試中發現並解決，而不是在對整個app進行編譯和啓動、運行、打開瀏覽器、輸入用戶名、密碼，手工集成測試之後才發現問題，而這一系列過程所花的時間完全不止1分鐘這麼短，有可能是5分鐘——完全可以來JavaEye灌水了！
如果把集成測試都累積做完之後，整個app會形成一個很完整的測試體系，再通過持續化集成工具來輔助實現集成自動化，專門拉到一臺測試服務器做集成，J.B.說的那個1分鐘問題其實可以完全避免，因此我認爲J.B.的陰謀論有些牽強。當然，集成測試必須建立在單元測試之上，這點毋庸置疑，集成測試的重點應該根據項目實情做出策略上調整，比如對集成目標、深度的制定上做修正。