【发布时间】：2009-11-25 07:01:16
【问题描述】：
我有超过 270 个项目的解决方案，它包含各种文件夹等。想象一下每个项目都有单元测试，你认为组织它们的最佳方式是什么？如果每个项目附近都有单元测试，或者我应该为它们创建特殊文件夹，甚至为单元测试创建不同的解决方案。
对于如此大的解决方案/项目，您如何组织它们？
【问题讨论】：
标签： .net unit-testing
【发布时间】：2009-11-25 07:01:16
【问题描述】：
每个目标项目应该有一个（或多个）单元测试项目。这是您保持灵活性并随目标项目一起改变每个单元测试套件的唯一方法。
如果您有一个单元测试项目覆盖多个目标项目，这会在这两个项目之间产生一种人为的紧密耦合，因为如果没有所有这些，您将无法编译单元测试项目其目标项目。这再次使得单独测试单个项目变得非常困难——这就是单元测试的全部意义所在。
如果您需要在多个测试目标之间共享测试代码，您始终可以使用通用的、可重用的测试 API 创建一个共享库，只要它不引用任何目标项目即可。
也就是说，我必须同意 Jon Skeet 的观点，即包含 270 个项目的解决方案是一种结构性问题，必须首先解决（除非它是用于自动构建的“全部构建”解决方案）。
【讨论】：
包含 270 个项目的单一解决方案听起来像是一个问题。打开VS需要多长时间？ :)（说真的，您可以将一些项目组合在一起还是拆分解决方案？）
通常我将单元测试保存在他们自己的项目中，但在同一个解决方案中。在项目中，镜像生产项目的文件夹/命名空间结构。看看Noda Time 是如何组织的，例如。我去过一些公司，他们被单独保存在一个单独的解决方案中，但这真的很痛苦。 （他们有一个很好的理由：测试是在 VS2005 中，生产代码是 2003 年。）
有时我将测试项目的默认命名空间设置为与生产项目相同 - 这在 Java 中比在 .NET 中更重要（因为它允许您访问包访问成员）但它仍然很有帮助因为这意味着您要测试的类不需要导入。
【讨论】：
-
1 个单元测试项目是要走的路。我们试图镜像我们的项目并为每个项目创建测试项目——结果都是测试失败。
-
我不喜欢将它们放在一个单独的项目中，因为这会使测试内部类和方法变得更加困难。
-
@Arnis：为什么？我从来没有发现每个生产项目一个测试项目有任何问题。你遇到了什么问题？
-
@tster：这就是 InternalsVisibleToAttribute 的用途。请参阅msdn.microsoft.com/en-us/library/… - 而对于生产项目中的测试代码，您最终会从生产程序集中引用测试框架等，并且在程序集中也拥有所有测试代码（以及潜在的大量测试数据） .伊克。
-
@Jon，我非常喜欢这一幕！！！我每天都在学习新东西。这太棒了！
从内置的 Visual Studio 测试框架切换到 Gallio 后，我开始将我的测试放在同一个项目的 Test 文件夹中。对于小助手类，我什至可以在同一个文件夹中定义一个单元测试。只要您的命名空间相对较小（我不喜欢庞大的命名空间文件夹），这不会给我增加太多混乱。无论如何，稍后，当这些类已经存在一段时间并且稳定时，您可以将这些单元测试移动到单独的文件夹中。
【讨论】：
-
所以当你发布你的生产二进制文件时，他们还有测试类吗？您是否也发布了测试框架程序集，大概是您的项目引用的？测试数据呢？
-
我从来没有考虑过太多，因为我从事的是内部应用程序。但是，是的，我想测试代码将被发送。我以后会考虑这个的。