從單元測試到集成測試的有效過渡

Question

我正在研究如何在即將開展的項目中執行測試。 為了在開發過程的早期發現錯誤，開發人員將在實際代碼（TDDish）之前編寫單元測試。 單元測試將單獨關注單元（在這種情況下是一種方法），因此依賴性將被模擬等等。

現在，我還想在與其他單位交互時對這些單元進行測試，我認為應該有一個有效的最佳實踐，因為已經編寫了單元測試。 我的想法是單元測試將被重用，但被模擬的對象將被刪除並替換為真實的對象。 我現在的不同想法是：

• 在每個測試類中使用全局標志，該標志決定是否應使用模擬對象。 這種方法需要幾個if語句
• 使用創建“instanceWithMocks”或“instanceWithoutMocks”的工廠類。 這種方法對於新開發人員來說可能很麻煩並且需要一些額外的類
• 將集成測試與不同類中的單元測試分開。 然而，這將需要大量冗余代碼並且維護測試用例將是工作的兩倍

我認為所有這些方法的方式都有利有弊。 哪個是首選，為什么？ 有沒有更好的方法從單元測試到集成測試的有效過渡？ 或者這通常以其他方式完成？

Answer 1

我會選擇第三種選擇

• 從不同類中的單元測試中分離集成測試。 然而，這將需要大量冗余代碼並且維護測試用例將是工作的兩倍

這是因為單元測試和集成測試有不同的目的。 單元測試表明，單獨的功能單獨工作。 集成測試表明，當它們彼此交互時，不同的功能仍然有效。

因此，對於單元測試，您希望模擬事物，以便您只測試一個功能。

對於集成測試模擬盡可能少。

我會把它們放在不同的項目中。 在我的地方運作良好的是使用NUnit和Moq進行單元測試項目。 編寫代碼時寫入TDD。 集成測試是Specflow / Selenium，功能文件是在計划會話中借助產品所有者編寫的，因此我們可以驗證我們是否提供了所有者想要的內容。

這確實可以在短期內創造額外的工作，但可以減少錯誤，更容易維護和交付匹配要求。

Answer 2

像Ninject / Autofac / StructureMap這樣的IoC容器可能對您有用。 單元測試可以通過容器解決被測系統，只需注冊是否有注冊的模擬或真實對象。 與您的工廠方法類似，但IoC容器是工廠。 新開發人員需要一些培訓才能理解，但任何復雜系統都是如此。 這樣做的缺點是注冊場景可能變得相當復雜，但是對於任何給定的系統來說，如果沒有嘗試它們是否太復雜就很難說。 我懷疑這是你沒有找到任何看似確定的答案的原因。

Answer 3

由於您正在測試不同的行為，因此集成測試應該是與單元測試不同的類。 我認為集成測試的方式是，它們是您在嘗試確保所有內容協同工作時執行的。 他們將使用輸入部分應用程序並確保返回預期的輸出。

Answer 4

我認為你搞砸了單元測試和集成測試的目的。 單元測試用於測試單個類 - 這是低級API。 集成測試正在測試類的協作方式。 這是另一個更高級別的API。 通常，您不能在集成測試中重用單元測試，因為它們代表不同級別的系統視圖。 使用spring上下文可能有助於為集成測試設置環境。

Answer 5

我不確定將單元測試重用於真實對象而不是模擬是實現集成測試的正確方法。

單元測試的目的是驗證與外界隔離的對象的基本正確性。 模擬是為了確保隔離。 如果你用真正的實現代替它們，你實際上最終會測試完全不同的東西 - 同一對象鏈的大部分的正確性，並且你多次對它進行冗余測試。

通過使集成測試與單元測試不同，您將能夠選擇要驗證的系統部分 - 通常，測試暗示配置，I / O，與第三方系統的交互的部分是個好主意， UI或其他任何單元測試都難以覆蓋的東西。

Answer 6

我同意大多數其他答案，單元測試應該與集成測試分開（選項3） 。

但我不同意你的反對意見：

[...]這個（來自集成測試的分離單元）將需要大量冗余代碼，並且維護測試用例將是工作的兩倍 。

使用測試數據生成對象可能需要大量工作，但這可以重構為測試助手，即ObjectMother ，可以在單元和集成測試中使用，因此不需要冗余

在單元測試中，您可以檢查測試中的類的不同條件。

對於集成測試，不需要重新檢查每個特殊情況。 而是檢查組件是否一起工作。

例

您可能會針對引發異常的4種不同情況進行單元測試。 對於集成，不需要重新測試所有4個條件。與異常相關的集成測試足以驗證集成系統是否可以處理異常。