你如何在一个大项目上组织你的修女测试?

要回答第一个问题:

你可以使用 categories 如果你想这样做的话,把所有的事情组织在一个集合中。至于它是否会缩短构建时间,我可能会冒险猜测,但我不认为这是一个巨大的总量。

回答第二个问题:

你可以使用 类别 以及 [Explicit] 和 [Ignore] 属性来告诉nunit要运行哪些测试,以及必须在运行之前告诉它要运行哪些测试。你可能还想看看 [Platform] 或者其他一些属性,具体取决于您对“环境”的具体要求。

例如,您可以向所有长时间运行的测试添加一个显式标记。然后您必须显式地运行这些测试,nunit不会自动运行它们。或者将所有这些测试添加到一个类别中,然后在运行nunit时,告诉它显式不要运行该类别。

对于您的情况,我将把它归结为几个选项:

• 将现有项目合并为较少的项目,从而为它们合并相应的测试项目 -如果您真的需要30个项目(例如30个程序集),或者最好简单地组合它们以减少依赖项的数量和构建时间。

• 将测试放入相应的项目中 -尽管这可能会引起强烈的反应,但想想看:考虑到大量的测试涉及到获得稍微大一点的组装的开销,可能值得减少管理两倍于您实际需要的项目的开销。

• 将所有单元测试合并到几个项目中 -如果您坚定不移地保持每个组件的干净和独立,那么您可以选择组合所有单元测试,可能是在相互关联方面。

因此,如果构建时间对您非常重要,那么您也可以进行不包括单元测试的解决方案配置。如果您只是在运行测试,这尤其有用 按需 . 如果您使用的是持续集成,那么这不应该是一个问题:您可以有多个CI配置,其中一些配置包括构建测试,而另一些配置不包括。

这是一个很好的问题,并引起了一些我对管理长时间运行的大型项目的大型单元测试集的关注。

我的策略是在您的解决方案中为每个与业务或框架相关的项目创建一个单元测试项目。单元测试不太适合测试项目的UI方面,我通常将其留给科学的测试。该项目是使用一个持续集成(CI)服务器构建的,每当开发人员提交一个工作块时,该服务器就会被激发。CI服务器还运行所有单元测试,并生成单元测试覆盖率统计信息。CI环境使用msbuild来构建解决方案。

随着时间的推移,有必要评估是否所有的单元测试都是必要的。很多回归测试工作将转移到脚本化测试,维护单元测试的开销可能很高。理想情况下,我希望在项目的整个生命周期内维护所有单元测试,但是维护开销有时会很高。根据经验法则,单元测试是为业务规则和解决方案框架维护的,而不是为UI、报告或工作流维护的。显然,这将取决于你的项目的细节。

作为旁白,我们发现 TestDriven.Net 要成为一个优秀的VisualStudio插件前端为nunit,免费开放源代码使用/学生。