我想看看能否改进我们在包含30多个项目的Visual Studio解决方案中使用NUnit的方式。
首先，您会为解决方案中的每个程序集创建一个测试程序集，还是尝试保持测试程序集的数量较少？我开始创建了许多测试程序集，但我认为这在构建时间上花费了我们很多时间。
其次，您如何管理那些长时间运行或需要特殊环境配置的测试？我想编写一个MSBuild脚本来自动运行我们的单元测试，但它需要跳过那些需要太长时间或在构建机器上无法运行的测试。
4个回答
6
回答你的第一个问题：
如果你想这样做，你可以使用类别在单个程序集中保持所有内容的组织。至于它是否会缩短构建时间，我猜可能会有一点点，但总体上不会很多。
回答你的第二个问题：
你可以使用类别和[Explicit]和[Ignore]属性告诉NUnit要运行哪些测试，以及在运行之前必须告诉它要运行哪些测试。根据你对“环境”的具体要求，你还可以查看[Platform]或其他属性。
例如，你可以给所有长时间运行的测试添加一个显式标记。然后你必须显式地运行这些测试，NUnit不会自动运行它们。或者把所有这些测试都添加到一个类别中，然后当你运行NUnit时，告诉它显式地不运行那个类别。
- monoxide
3
针对您的情况，我会提出以下几个选项：
将现有项目合并为较少的项目，并相应地合并测试项目 - 请考虑一下您是否真的需要30个项目（例如30个程序集），或者将它们合并以简化依赖关系和构建时间。
将测试放入其相应的项目中 - 虽然这可能会引起激烈反应，但请思考一下：考虑到涉及的大量测试，获取稍大一些的程序集的开销可能值得管理实际所需项目数量两倍的开销。
将所有单元测试组合成几个项目 - 如果您坚持保持每个程序集的清晰和分离，您可以选择将所有单元测试组合在一起，可能是与彼此相关的。
因此，您还可以创建不包括单元测试的解决方案配置 - 如果构建时间对您非常重要。如果您只是按需运行测试，则特别有用。如果您正在使用持续集成，这不应该是问题：您可以拥有多个CI配置，其中一些包括构建测试，一些则不包括。
- Jon Limjap
1
1关于您提到的第二点，您可以添加条件属性以避免膨胀的发布版本（可以创建TEST指令或使用DEBUG）。该属性可以在类或方法级别上添加。 - Guvante
1
这是一个很好的问题，也引发了我对于管理长时间运行、大型项目的大量单元测试的一些担忧。
我的策略是为解决方案中每个与业务或框架相关的项目都建立一个单元测试项目。单元测试不适合用于测试项目的 UI 方面，我通常将此留给脚本测试。该项目使用连续集成（CI）服务器构建，每当开发人员提交一块工作时就会触发 CI 服务器。CI 服务器还运行所有单元测试，并生成单元测试覆盖率统计信息。CI 环境使用 MSBuild 构建解决方案。
随着时间的推移，值得评估是否所有单元测试都是必要的。许多回归测试的工作将转移到脚本测试，而维护单元测试的开销可能很高。理想情况下，我希望在项目的整个生命周期内都能维护所有单元测试，但维护开销有时可能是禁止性的。作为经验法则，单元测试应该针对业务规则和解决方案框架进行维护，而不是针对 UI、报告或工作流程。显然，这将取决于您项目的具体情况。
- Richard Dorman
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接