如果一個項目有100％的單元測試覆蓋率，是否仍然需要集成測試？如果一個項目有100％的單元測試覆蓋率，是否仍然需要集成測試？
我從來沒有在100％單元測試覆蓋率的項目上工作過，但是我想知道您的項目是否獲得這個（或90％），您的體驗還是需要集成測試嗎？ （你需要更少？）
我問，因爲集成測試看起來很糟糕。它們通常是緩慢的，脆弱的（容易突破），不透明的（當某人不得不通過所有圖層來找出錯誤時），並且導致我們的項目放緩下來......我開始認爲有隻有單元測試（也許是一小撮煙霧測試）纔是最好的選擇。
從長遠來看，集成測試（根據我的經驗）似乎比他們節省的成本更高。
感謝您的考慮。
我認爲在進行此討論之前定義您的術語很重要。
單元測試單獨測試一個單元。對我來說，這是一堂課。單元測試將創建一個對象，調用一個方法並檢查結果。它回答了這個問題：「我的代碼是否按照我的意圖去做？」
集成測試測試系統中兩個組件的組合。它側重於組件之間的關係，而不是組件本身。它回答了「這些組件是否按預期一起工作」的問題。
系統測試測試整個軟件系統。它回答了這個問題：「這個軟件是否按照預期工作？」
驗收測試是一個自動化的方式，讓客戶回答「我想這個軟件是我想要的嗎？」這個問題。這是一種系統測試。
請注意，這些測試都不能回答「這個軟件有用嗎？」這樣的問題。或者「這個軟件容易使用？」。
所有的自動化測試都受限於公理「端到端比你想象的要進一步」「 - 人類最終必須坐在電腦前，看看你的用戶界面。
單元測試是更快，更容易編寫，運行更快，更容易診斷。它們不依賴於像文件系統或數據庫這樣的「外部」元素，因此它們更簡單/更快/更可靠。大多數單元測試在重構時繼續工作（並且良好的單元測試是安全重構的唯一方法）。他們絕對要求你的代碼是decoupled，這很難，除非你先寫測試。這些因素的結合使得TDD的紅/綠/重構序列工作得很好。
系統測試很難寫，因爲他們必須經過這麼多的設置才能達到想要測試的特定情況。它們很脆弱，因爲之前軟件行爲的任何變化都會影響到您想要測試的情況，即使這種行爲與測試無關。出於類似的原因，它們比單元測試慢得多。故障診斷可能非常困難，因爲故障可能需要很長時間才能完成，而且故障涉及的軟件太多。在某些軟件中，系統測試非常難以自動化。集成測試處於兩者之間：它們比系統測試更易於編寫，運行和診斷，但覆蓋範圍比單元測試更廣。
使用測試策略的組合來平衡每個的成本和值。
是的，除了有幾個不同類型的代碼覆蓋率
例如，僅僅因爲每個方法都被調用，並不意味着如果您按給定順序調用各種方法，則不會發生路徑覆蓋。
是的。
即使所有「單位」都做他們應該做的事情，但不能保證整個系統按設計工作。
單元測試與集成測試不同。只是爲了說明一點：如果我必須選擇，我會轉儲單元測試並進行集成測試。經驗告訴我們，單元測試有助於確保功能，並在開發週期的早期發現錯誤。
集成測試是在產品看起來接近最終用戶的情況下完成的。這一點也很重要。
單元測試通常都是關於單獨測試你的課程。他們的設計應該確保您的班級具有可預測和預期的行爲。
集成測試通常都是關於如何組合測試您的課程以及使用這些課程的「外部」程序。他們應該專注於確保當整個產品使用您的課程時，它以正確的方式進行。
是的，因爲你的軟件的功能取決於它如何與不同的部件進行交互。單元測試取決於您輸入輸入和定義預期輸出。這樣做並不能保證它可以與你係統的其他部分一起工作。
是的集成測試是一個痛苦的問題，當您引入代碼更改故意更改輸出。通過我們的軟件，我們可以通過將集成測試的保存結果與保存的正確結果進行比較來最大限度地減少此問題。
我們有一個工具，可以使用，當我們確信我們正在產生正確的結果。它會加載舊保存的正確結果並修改它們以使用新的設置。
首先，即使在單元測試級別，100％的單元測試覆蓋率也不夠：只覆蓋代碼指令的100％。你的代碼中的路徑怎麼樣？輸入或輸出域如何？
其次，您不知道發送器單元的輸出是否與來自其接收器單元的輸入兼容。這是集成測試的目的。
最後，單元測試可能在與生產不同的環境下執行。集成測試可能會顯示差異。
「不透明（當某人不得不穿透所有圖層以找出錯誤時）」 - 這正是集成測試完成的原因 - 否則這些不透明的問題將顯示在生產環境中。
我經常看到好的集成測試發現的各種問題 - 特別是如果您可以自動化一些集成測試。
單元測試很好，但是您可以在單元測試中沒有100％相關性的情況下完成100％的代碼覆蓋率。你真的想要測試不同的東西，對吧？在單元測試中，通常是針對特定功能尋找邊緣案例，而集成測試將在所有這些功能交互時向更高層展示問題。
如果你在你的軟件中建立一個API，你可以用它來進行自動集成測試 - 過去我已經獲得了很多里程數。我不知道我會盡可能地說我傾向於單元測試而不是集成測試，但是當它們做得正確時，它們是一個非常強大的補充。
This exact question基本上剛剛問過一天前。請參閱this question瞭解可能會遇到的很多錯誤，即使使用100％的代碼覆蓋率也是如此。
您只能使用測試/覆蓋來證明存在錯誤，但您永遠無法使用測試/覆蓋來證明該代碼沒有錯誤。這個事實表明了測試/覆蓋的界限。這在數學上是一樣的，你可以通過找到一個反例來駁倒一個定理，但是你永遠不能通過找到一個反例來證明一個定理。因此，測試和覆蓋僅僅是正確性證明的替代品，這些證據很難做到幾乎從不使用。測試和覆蓋可以提高代碼的質量，但不能保證。它仍然是一門手藝而不是科學。
它看起來並不像這裏提到的那樣，但你實際上從來沒有100％的單元測試覆蓋率（如果你有一個數據庫）。當您爲數據庫連接和CRUD操作編寫單元測試時，您剛剛創建了一個集成測試。原因是因爲您的測試現在在各個工作單元之外有依賴性。我所從事的項目以及與之交談過的開發人員一直都表示剩餘的10％是DAO或服務層。最好的測試方法是使用集成測試和模擬（內存）數據庫。我已經看到爲了單元測試DAO而嘗試模擬連接，但我並沒有真正看到這一點 - 您的DAO只是將原始數據從一種格式序列化到另一種格式的一種方式，而您的經理或代表將決定如何操縱它。
我還沒有真正看到涵蓋這些考慮的答案。現在，我從整體系統角度來講，並不構成軟件開發的角度，但... 集成基本上是將低級產品組合到更高級別產品中的過程。每個級別都有自己的一套要求。儘管某些要求可能相同，但對於不同的等級，總體要求會有所不同。這意味着不同級別的測試目標是不同的。另外，較高級別產品的環境環境往往與較低級別產品的環境環境不同（例如，SW模塊測試可能發生在桌面環境中，而完整的可加載SW項目可能在加載到其HW中時被測試零件）。此外，較低級別的組件開發人員可能與高級產品開發人員對「需求和設計」的理解不一樣，所以集成測試也在一定程度上驗證了較低級別的產品開發。
如果「經驗告訴單元測試有助於確保功能並在開發週期的早期發現錯誤」。爲什麼你要「傾倒單元測試並進行集成測試」？ – 2009-02-17 15:43:07
「只是爲了表達一點」。舊時間練習一直是爲了完成測試工作。經驗表明，如果您早期進行測試（並且迭代地），則有一些優勢，例如儘早發現錯誤。現在，如果我傾銷單元測試進行集成測試，那麼我會失去這種優勢，但我的項目仍然存在。 – Sesh 2009-02-17 15:59:54