.net - 您如何在 .Net 中设置单元测试项目？

Question

您能否分享在 .net 解决方案中设置单元测试项目的方式？

我可以想象几种可能的方法。例如:

有一个单独的单元测试解决方案，完美地反射(reflect)了正在测试的原始代码解决方案的结构。

在原始代码解决方案中，有一个解决方案文件夹，您可以在其中完美镜像...

每个代码项目都有一个单元测试项目，并与它一起位于解决方案的树结构中。

有一个单元测试项目，涵盖在树结构中与它们并排的多个代码项目。

很想听听您在解决方案中实际是如何做到的。

Answer 1

IMO，如果您想让测试易于运行，测试项目绝对必须与生产代码使用相同的解决方案。虽然如果所有开发人员都非常勤奋，将测试放在另一个解决方案中可能会奏效，但它在更改生产代码和运行测试之间增加了额外的障碍。我倾向于尽可能多地消除障碍。

有几种不同的方法可以做到这一点。

每个解决方案一个测试项目 (Product.UnitTests.csproj)

每个系统一个测试项目 (Product.SystemName.UnitTests.csproj)

生产项目和测试项目的一对一映射(Product.ProjectName.csproj 和 Product.ProjectName.Tests.csproj)

每个都有自己的权衡，你必须权衡。

每个解决方案的单个测试项目

如果整个解决方案包含有凝聚力的项目，则有意义。如果您总是要使用相同的解决方案进行开发，那么拥有一个集中的测试项目会很好。

这意味着您的构建过程中的开销减少了(当您的解决方案包含大量项目时，减少程序集数量也减少了构建时间)并且没有维护 .nunit 文件等的开销。

此外，每个人都知道测试的去向。缺点是您必须使用命名空间来划分不同的生产项目，并且一个项目的测试现在与其他项目相关联。 IE。这是“最容易”获得认可的一种，因为需要跟踪的东西更少，并且开发人员可以轻松地运行测试。缺点是在某些情况下，这不适合您正在开发的内容。

每个系统单个测试项目

基本上和上面一样，只是粒度更细。您将相关项目分组到区域/系统中，并为每个区域/系统使用一个测试程序集。这稍微增加了复杂性，但也意味着系统更容易在其他解决方案中提取/重用。

生产项目和测试项目的一对一映射

在创建新程序集方面开销最大，当有大量项目时会稍微增加构建时间，并且通常会使您的解决方案文件更大。在始终保持 .nunit 项目文件最新方面需要尽职尽责，并且不能很好地与 IDE 单元测试配合使用。

好处是为每个生产项目维护一个测试项目意味着测试只依赖于他们正在测试的功能(因此更容易重用项目)并且您可以通过运行一个项目更轻松地检查代码覆盖率一次(而如果您运行所有测试，由于不相关的测试有时会触及他们不感兴趣的代码，您将获得更高的覆盖率)。此外，这是一个简单的模式，因此人们会明白测试的目的是什么，没有问题。

总结:我认为以上任何一种方法都可以很好地工作，具体取决于您正在开发的内容，但是如果您想要一个“正常工作”的解决方案，那么我倾向于使用一对一的映射。