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