我的隊友現在已經理解（!?）集成測試和單元測試之間的區別。現在在我們的項目中爲每個組件建立一個測試組件。在同一個組件中混合單元測試和集成測試
集成測試目前沒有像SpecFlow或Cucumber這樣的特殊框架。他們是簡單的（和長）NUnit測試方法，來自不同程序集的幾個類一起被測試。
該計劃現在使用「單元測試」和「集成測試」按屬性（C＃）對測試進行分類，以便NUnit可以在必要時過濾相應的測試。
在同一個程序集中混合集成測試和單元測試是否合適，還是應該總是將它們分離到不同的程序集中？
從技術上講，這可能工作，但你爲什麼要這麼做？
儘管單元測試是測試一個「單元」，它可能是測試程序集所屬程序集所屬的程序集內的一個函數或任何其他小代碼段（一個測試程序集用於每個程序集）測試通常在多個程序集中實現的邏輯，因此爲集成測試添加一個額外的程序集並將它們與單元測試分開，實際上是我眼中更好的配置。
從一些相關article閱讀：
集成測試在單元測試驗證 一塊孤立代碼的功能，集成測試驗證的一段代碼的針對目標系統的功能 或平臺。就像單元 測試一樣，集成測試是在 測試框架內運行的自動程序。儘管全面的單元測試驗證了代碼的行爲與預期的隔離，但您仍需確保 您的代碼在其目標環境中的行爲與預期相符，並且您的代碼所依賴的外部系統的行爲與預期相同。 這就是進行集成測試的地方。與單元測試不同， 集成測試會執行測試中每種方法 的呼叫路徑中的所有代碼，而不管該代碼是否在您正在測試的類中 ，或者是測試的一部分外部API。正因爲如此，設置集成測試的測試條件需要很長的時間。例如，對於 示例，您可能需要創建用戶和組或添加列表並列出 項目。集成測試的運行時間也相當長。然而，與單元測試不同，集成測試並不依賴於關於外部系統和服務行爲的假設。作爲 的結果，集成測試可能會檢測到錯誤的單元 測試的錯誤。開發人員經常使用集成測試來驗證外部依賴性（如Web服務）的行爲是否符合預期，或者測試 代碼嚴重依賴於不能被 分解的外部依賴性。測試人員還經常開發和使用更多不同場景的集成測試，例如安全測試和壓力測試。 在許多情況下，組織不區分集成 和單元測試，因爲這兩種類型的測試通常由 單元測試框架驅動，例如nUnit，xUnit和Visual Studio單元 測試。通常，使用敏捷開發實踐 的組織會做出這種區分，因爲這兩種類型的測試在敏捷過程中具有不同的 目的。