我的队友现在已经理解（!?）集成测试和单元测试之间的区别。现在在我们的项目中为每个组件建立一个测试组件。在同一个组件中混合单元测试和集成测试
集成测试目前没有像SpecFlow或Cucumber这样的特殊框架。他们是简单的（和长）NUnit测试方法，来自不同程序集的几个类一起被测试。
该计划现在使用“单元测试”和“集成测试”按属性（C＃）对测试进行分类，以便NUnit可以在必要时过滤相应的测试。
在同一个程序集中混合集成测试和单元测试是否合适，还是应该总是将它们分离到不同的程序集中？
从技术上讲，这可能工作，但你为什么要这么做？
尽管单元测试是测试一个“单元”，它可能是测试程序集所属程序集所属的程序集内的一个函数或任何其他小代码段（一个测试程序集用于每个程序集）测试通常在多个程序集中实现的逻辑，因此为集成测试添加一个额外的程序集并将它们与单元测试分开，实际上是我眼中更好的配置。
从一些相关article阅读：
集成测试在单元测试验证 一块孤立代码的功能，集成测试验证的一段代码的针对目标系统的功能 或平台。就像单元 测试一样，集成测试是在 测试框架内运行的自动程序。尽管全面的单元测试验证了代码的行为与预期的隔离，但您仍需确保 您的代码在其目标环境中的行为与预期相符，并且您的代码所依赖的外部系统的行为与预期相同。 这就是进行集成测试的地方。与单元测试不同， 集成测试会执行测试中每种方法 的呼叫路径中的所有代码，而不管该代码是否在您正在测试的类中 ，或者是测试的一部分外部API。正因为如此，设置集成测试的测试条件需要很长的时间。例如，对于 示例，您可能需要创建用户和组或添加列表并列出 项目。集成测试的运行时间也相当长。然而，与单元测试不同，集成测试并不依赖于关于外部系统和服务行为的假设。作为 的结果，集成测试可能会检测到错误的单元 测试的错误。开发人员经常使用集成测试来验证外部依赖性（如Web服务）的行为是否符合预期，或者测试 代码严重依赖于不能被 分解的外部依赖性。测试人员还经常开发和使用更多不同场景的集成测试，例如安全测试和压力测试。 在许多情况下，组织不区分集成 和单元测试，因为这两种类型的测试通常由 单元测试框架驱动，例如nUnit，xUnit和Visual Studio单元 测试。通常，使用敏捷开发实践 的组织会做出这种区分，因为这两种类型的测试在敏捷过程中具有不同的 目的。