在同一个程序集中混合单元测试和集成测试

Question

我的队友现在已经理解（！？）集成测试和单元测试之间的区别。现在在我们的项目中，为每个程序集建立了一个测试程序集。

目前编写的集成测试没有像 SpecFlow 或 Cucumber 这样的特殊框架。它们是简单（且长）的 NUnit 测试方法，其中来自不同程序集的多个类一起进行测试。

现在的计划是使用“单元测试”和“集成测试”按属性（C#）对测试进行分类，以便 NUnit 可以在必要时过滤适当的测试。

在同一个程序集中混合集成测试和单元测试是否合适，还是应该始终在不同的程序集中分开？

Answer 1

从技术上讲，这可能可行，但为什么要这样做呢？

\n\n

虽然单元测试是测试一个“单元”，它可能是测试程序集所属的程序集中的一个函数或任何其他小段代码（每个程序集一个测试程序集），但集成测试是关于测试一些逻辑，通常在多个程序集中实现，因此在我看来，为集成测试提供一个额外的程序集并将其与单元测试分开实际上是一种更好的配置。

\n\n

从一些相关文章中阅读此内容：

\n\n

\n

集成测试 单元测试单独验证一段代码的功能，而集成测试则针对目标系统或平台验证一段代码的功能。就像单元测试一样，集成测试是在测试框架内运行的自动化过程。尽管全面的单元测试可以验证您的代码在单独情况下是否按预期运行，但您仍然需要确保您的代码在其目标环境中按预期运行，并且代码所依赖的外部系统按预期运行。 \n 这就是集成测试的用武之地。与单元测试不同，\n 集成测试会执行 test\xe2\x80\x94 下每个方法\n 的调用路径中的所有代码，无论该代码是否在您所在的类中\n 测试或者是外部 API 的一部分。因此，设置集成测试的测试条件需要更长的时间。例如，您可能需要创建用户和组或添加列表和列表项。集成测试的运行时间也相当长。\n 但是，与单元测试不同，集成测试不依赖\n 关于外部系统和服务行为的假设。因此，集成测试可能会检测到单元测试遗漏的错误。开发人员经常使用集成测试来验证外部依赖项（例如 Web 服务）是否按预期运行，或者测试严重依赖于无法分解的外部依赖项的代码。测试人员还经常为更多样化的场景开发和使用集成测试，例如安全测试和压力测试。在许多情况下，组织不区分集成测试和单元测试，因为这两种类型的测试通常都是由\n 单元测试框架，例如 nUnit、xUnit 和 Visual Studio Unit\n 测试。通常，使用敏捷开发实践的组织会做出这种区分，因为两种类型的测试在敏捷过程中具有不同的目的。

\n

\n