.NET 单元测试项目组织答案

【问题标题】：.NET unit testing projects organisation.NET 单元测试项目组织
【发布时间】：2012-05-05 05:05:01
【问题描述】：

您认为在大型 .net 应用程序中管理单元测试的最佳方式是什么？是为解决方案中的每个单独项目添加一个测试项目，还是为其余项目中的所有测试添加一个大型测试项目更好？

例如，如果一个解决方案中有 10 个项目，是增加 10 个额外的测试项目更好，还是一个大型测试项目足以满足整个解决方案？

我知道模块化测试程序集提供了一些好处，但是使用测试类别可以实现非常相似的事情。很多项目编译需要的时间比较长，但是你可以排除你当时不需要的项目，而如果你只有一个项目你不能这样做，但是编译需要的时间会少一些。

请在你的答案中概述每个选择的优点/缺点。

【问题讨论】：

【解决方案1】：

就个人而言，我更喜欢每个实际项目都有一个专门的测试项目。在构建新功能/模块/项目时，我发现能够快速过滤掉其他不相关的测试项目套件要好得多。它使 TDD 周期快得多，以便能够在我开发新项目时快速运行测试。

更重要的是，它可以帮助您根据需要为您的设备维护一个良好的各种测试/模拟类的组织，而不会将大量不相关的代码混在一起。它还使新开发人员更容易找到相关的测试。最后，它确保您对特定项目的测试的依赖关系不会意外地依赖于另一个不相关的项目。

【讨论】：

【解决方案2】：

Phil Haack 写了一篇关于单元测试结构的好文章。这已成为我编写单元测试时的个人最佳实践。这是他的文章的链接http://haacked.com/archive/2012/01/02/structuring-unit-tests.aspx

至于您的问题，我总是会为单元测试创建一个单独的项目，并将其命名为 .UnitTests 附加（我这样做是为了区分单元测试和集成测试）。例如，如果我的主项目是 Sample.WebUI，则测试将是 Sample.WebUI.UnitTests。

单元测试确实会增加编译时间，但我认为这是一个小问题。我正在研究一个包含 17 个项目（不包括单元测试）的解决方案，编译所有内容大约需要 50-60 秒。差不多有足够的时间把我的视线从显示器上移开，看看别的东西来改变一下:-)

关于类别，如果您有一些日常构建需要快速完成测试，那么请使用它们并将它们与那些需要更长时间才能完成的测试（如集成测试）区分开来。此外，如果您使用的是 TFS，则使用类别可以帮助自动化和测试您的签入。

【讨论】：

测试类别非常适合 CI，尤其是 Selenium 测试。您可以为给定的工作项编写用户故事，为其生成硒测试，然后一旦工作项完成，在签入时，工作项的这些测试将与整个回归套件一起执行。这有助于防止许多微小的错误被部署到 ci 管道的下方。现在我认为我确信每个实际项目都创建一个测试项目。

【解决方案3】：

我个人的选择是每个项目有一个测试项目，只有单元测试。这个testproject的文件夹结构和被测试的项目完全一样。除此之外，还可以根据需要制作尽可能多的集成测试项目。

这种方法的主要优点是，当您想要将 1 个项目用于不同的解决方案时，您总是将测试项目放在一起，以确保当您必须在新解决方案中创造机会时，质量保持不变。

到目前为止，除了在使用一个测试项目时必须替换引用之外，我没有发现任何缺点。

【讨论】：