使用 TestCategory 分解集成测试有什么好处吗？答案

【问题标题】：Is there a benefit to breaking up Integration tests with TestCategory?使用 TestCategory 分解集成测试有什么好处吗？
【发布时间】：2013-08-14 13:09:48
【问题描述】：

我们的解决方案最终将是大型企业，因此集成测试的数量将会增加（虽然目前还很小）。我们的目标是实现近乎连续的部署（提交和发布之间的 2 天）。

我们在 MyProj.Tests.Unit 中有单元测试，在 MyProj.Tests.Integration 中有集成测试。我们将 TFS 云持续集成用于单元测试，并使用一个特殊的构建来为集成测试运行一个虚拟环境。单元测试和集成测试之间的分离不是这里的问题，问题是分离集成测试有什么好处。

对我们而言，集成测试是那些需要外部资源（例如数据库或测试 Web 服务）的测试。我们正在尝试决定是否使用 TestCategory 按测试所需的资源来标记测试，例如：

[TestCategory("NeedsDB")]

或

[TestCategory("NeedsServiceX")]

我们当前的集成测试环境很快，但由于我们处于项目的早期阶段，因此负载并不大。一些开发人员提到，通过属性查看方法需要什么很有用，但我更喜欢开发人员使用他们的眼睛和大脑，而不是依赖需要手动更新的属性。

我正在尝试确定以这种方式标记测试是否是样板 YAGNI。

如果我现在不对集成测试进行分区，我将来会不会遇到问题？
我们是否以这种方式滥用了 TestCategory 属性？是不是为了别的？

【问题讨论】：

标签： .net testing integration-testing mstest

【解决方案1】：

MSTest 的一个问题是您必须使用类别标记每个测试，而不是使用 NUnit 标记整个夹具。我怀疑您能否在大中型项目中使类别保持最新。与现在尝试解决不存在的问题相比，当它在未来真正出现时，您是否会更好地解决问题。当您最终确实遇到问题时，您将能够更好地解决问题。

【讨论】：

【解决方案2】：

假设该工具允许您按类别选择和运行测试，随着测试套件的大小和执行时间的增长，它会派上用场。例如，您可以有一个与当前版本相关的测试类别，第二个称为基本核心，另一个称为回归类别，然后在构建管道中以不同的点和频率运行它们。

【讨论】：