您可以分享在.net解决方案中设置单元测试项目的方式吗？
我可以想象几种可能的方法。例如：
为单元测试提供单独的解决方案，完美地镜像正在测试的原始代码解决方案的结构。
在原始代码解决方案中，有一个解决方案文件夹，您可以在其中完美地镜像...
为每个代码项目提供一个单元测试项目，并在解决方案的树结构中与其一起驻留。
有一个单元测试项目，涵盖在树形结构中与它们并存的几个代码项目。
很想知道你在解决方案中是如何实际做到的。
答案 0 :(得分：10)
绝对是单一的解决方案，但是单独的项目：
每个生产项目的一个测试项目对我来说效果很好。我倾向于使命名空间对于测试和生产代码都相同，这意味着您通常不需要使用指令。
答案 1 :(得分：10)
IMO，如果您想让测试易于运行，测试项目绝对必须与生产代码在同一解决方案中。如果所有开发人员都非常勤奋，那么将测试放在另一个解决方案中可能会有效，但它会在更改生产代码和运行测试之间增加额外的障碍。我倾向于选择尽可能多的障碍。
有几种不同的方法可以做到。
每个人都有自己的权衡，你必须权衡。
每个解决方案的单个测试项目
如果整个解决方案包含有凝聚力的项目，则有意义。如果您总是要使用相同的解决方案进行开发，那么拥有一个集中的测试项目会很不错。
这意味着您的构建过程的开销会减少（当您拥有大量项目的解决方案时，减少组装计数也会缩短构建时间）并且没有维护.nunit文件等的开销。
此外，每个人都知道测试的去向。缺点是您必须使用命名空间来划分不同的生产项目，现在一个项目的测试与其他项目相关联。即这是最容易获得支持的，因为跟踪的次数较少，开发人员可以轻松地进行测试。缺点是在某些情况下，这不适合你正在开发的东西。
每个系统的单个测试项目
基本上和上面一样，除了它的细粒度。您将相关项目分组到区域/系统中，并为每个项目使用单个测试程序集。这会稍微增加复杂性，但也意味着系统在其他解决方案中更容易提取/重复使用。
生产项目和测试项目的一对一映射
在创建新程序集方面开销最大，在项目负载时会略微增加构建时间，并且通常会使解决方案文件更大。需要尽职尽责地保持.nunit项目文件是最新的，并且在IDE单元测试中不能很好地发挥作用。
最重要的是，为每个生产项目维护一个测试项目意味着测试只依赖于他们正在测试的功能（因此更容易重用项目），您可以更轻松地检查代码覆盖率一次运行一个项目（如果你运行所有的测试，你将获得更高的覆盖率，因为无关的测试有时会触及他们不感兴趣的代码）。此外，这是一个简单的模式，因此人们将了解测试的目的是什么。
总结：我认为上述任何一项都可以很好地运行，具体取决于你正在开发的内容，但如果你想要一个“正常”的解决方案，那么我倾向于选择一对一的映射。
答案 2 :(得分：1)
以下结构对我来说效果很好。它还使生产和测试代码分开。
\source
\source\code\MainSolution.sln
\source\code\Project1
\source\code\...
\source\test\TestSolution.sln
\source\test\TestProject1
\source\test\...
答案 3 :(得分：0)
为两个项目提供相同的解决方案，但是两个项目，.NET项目和NUnit项目（一对一），现在如果我有一个包含多个项目的解决方案，那么我只有1个NUnit项目用于解决方案每个项目都有1个。我认为这是一个好方法，因为它可以帮助我组织我的项目。
另外，你可以看看这本书：http://www.artofunittesting.com/它非常好。
答案 4 :(得分：0)
我更喜欢在与我的源代码相同的解决方案中使用测试项目，并通过添加文件夹
对测试进行分组