我很想看看我是否可以改进我们在包含 30 多个项目的 Visual Studio 解决方案中使用 NUnit 的方式。
首先，您是否会为解决方案中的每个程序集设置一个测试程序集，或者您会尝试减少测试程序集的数量？我开始创建许多测试程序集，但我认为这在构建时间方面花费了我们很多。
其次，您使用什么策略来管理那些长时间运行或需要特殊环境配置的测试？我想编写一个 MSBuild 脚本来自动运行我们的单元测试，但它需要跳过那些耗时太长或无法在构建机器上运行的测试。
【问题讨论】：
标签： unit-testing nunit
回答你的第一个问题：
如果您愿意，可以使用categories 将所有内容组织在一个程序集中。至于它是否会减少构建时间，我可能会冒险猜测，但我认为总体上不会是一个巨大的数量。
回答你的第二个问题：
您可以使用categories 和[Explicit] 和[Ignore] 属性来告诉NUnit 哪些测试要运行，哪些测试你必须告诉它在它运行之前运行。您可能还想查看[Platform] 或其他一些属性，具体取决于您对“环境”的具体要求。
例如，您可以在所有长时间运行的测试中添加一个显式标记。然后你必须明确地运行这些测试，NUnit 不会自动运行它们。或者将所有这些测试添加到一个类别中，然后在运行 NUnit 时，告诉它明确不运行该类别。
【讨论】：
对于您的情况，我将其归结为几个选项：
将现有项目合并到更少的项目中，从而为它们合并相应的测试项目 - 尝试考虑您是否真的需要 30 个项目（例如，30 个程序集），或者是否更好只需将它们组合起来即可减少依赖项的数量和构建时间。
将您的测试放入相应的项目中 - 虽然这可能会引起剧烈反应，但请考虑一下：考虑到大量测试涉及获得稍大的程序集的开销可能是管理两倍于您实际需要的项目的开销是值得的。
将所有单元测试合并到几个项目中 - 如果您坚持保持每个程序集的清洁和独立，您可以选择合并所有单元测试，可能是在相互关联。
因此，您还可以进行不包括单元测试的解决方案配置 - 如果您非常关心构建时间。如果您只是按需运行，这将特别有用。如果您使用的是持续集成，这应该不是问题：您可以有多个 CI 配置，其中一些包括构建测试，一些不包括。
【讨论】：
这是一个很好的问题，并引发了我对为长期运行的大型项目管理大量单元测试的一些担忧。
我的策略是为解决方案中的每个与业务或框架相关的项目创建一个单元测试项目。单元测试不太适合测试项目的 UI 方面，我通常将其留给 scipted 测试。该项目是使用持续集成 (CI) 服务器构建的，每次开发人员提交大量工作时都会触发该服务器。 CI 服务器还运行所有单元测试以及生成单元测试覆盖率统计信息。 CI 环境使用 MSBuild 构建解决方案。
随着时间的推移，有必要评估您的所有单元测试是否都是必要的。许多回归测试工作将转向脚本测试，维护单元测试的开销可能会很昂贵。理想情况下，我希望在项目的整个生命周期内维护所有单元测试，但维护开销有时可能会令人望而却步。根据经验，单元测试是为业务规则和解决方案框架维护的，而不是为 UI、报告或工作流维护的。显然，这将取决于您的项目的具体情况。
【讨论】：
顺便说一句，我们发现 TestDriven.Net 是 NUnit 的优秀 VisualStudio 插件前端，免费供开源使用/学生使用。
【讨论】：