【发布时间】：2008-11-06 18:20:43
【问题描述】：
在 .NET 中，您应该将单元测试项目与解决方案的其余部分放在一起吗？还是应该有一个包含所有测试项目的测试解决方案？
我们的代码库解决方案包含所有测试项目……这似乎有点麻烦。
你平时做什么？
【问题讨论】：
标签： .net visual-studio unit-testing solution
【发布时间】：2008-11-06 18:20:43
【问题描述】：
在我们当前的项目中，我们决定将所有单元测试放在单独的项目中。应用程序代码和测试在同一个解决方案中，但至少我们可以构建（和部署）一个没有单元测试代码的版本。
到目前为止，这样做的缺点是有时您的单元测试无法到达应用程序代码的某些成员（受保护的和内部的），但这通常会导致我们发现我们的设计可以改进。
我想我应该指出一个类似的线程Here，在相同/相似的主题上有更多的答案。
【讨论】：
-
尝试 InternalsVisibleToAttribute（目标程序集），然后您的单元测试可以访问内部成员。 private 需要使用反射的hackarounds，所以如果它们需要独立测试，我总是将它们标记为内部。
-
（而且我认为 OP 已经在按照您的建议进行操作，他想知道解决方案是否应该有多个测试项目，或者是否应该有一个单独的解决方案只包含测试项目。）
-
cfeduke：感谢您将我指向 InternalsVisibleToAttribute！
我一直将它们作为解决方案的一部分 - 毕竟，它们是解决方案的一部分。您可以有多种解决方案，但可以使用不同的方法来查看您的项目，因此您可能希望在某些情况下创建无测试解决方案。
【讨论】：
我们的测试代码不会发布，但它们是整个解决方案的一部分。我们的构建器分离出测试组件和核心组件。从解决方案管理的角度来看，一个包含 140 多个项目的解决方案似乎是压倒性的。
【讨论】：
-
我们经历了这个过程，并且在某个时候，我们将过去包含 60 多个项目的单一解决方案拆分为 2 或 3 个解决方案。不过，测试项目与他们测试的应用程序代码仍然在同一个解决方案中。
-
这对我来说似乎是一个可靠的解决方案。
我们总是在同一个解决方案中使用单独的项目。
这意味着我们可以确定（使用引用）单元测试代码也测试我们的显式引用（而不是隐式地获取某些可见性，因为它在同一个程序集中——例如“内部”）
【讨论】：
通常我将单元测试放在他们自己的项目中，并将集成测试放在他们自己的应用程序解决方案中的项目中。
在我工作的地方，我们正在考虑将 Web 测试放在单独的解决方案中。我们计划与 QA 团队共享 Web 测试创作，我们不希望这些测试成为构建责任。
【讨论】：
我不使用 .NET，但是当我开发任何类型的测试用例时，我会将它们与其余代码隔离开来，这样我就可以在没有测试的情况下部署应用程序。用户不需要，甚至不需要这些东西。
【讨论】：
-
看你不使用.NET，你显然不理解“解决方案”的概念。将应用程序项目和测试项目放在同一个解决方案中并不意味着测试包含在您实际提供给最终用户的产品中。
看看你的项目的设计。如果它靠近 MVC 布局或其替代方案之一，那么您应该有不同级别的不同程序集。为每个设计级别制作一个测试子组件。
我们的测试项目通常代替创建 EXE 的项目运行。我们的 EXE 项目是一个薄壳，它将事件和信息传递给一个装满控制器类的程序集，其中包含大多数人放入 EXE 项目中的代码。这允许测试项目在 90% 的正常测试过程中伪装成 EXE。
我们仍在为实际测试用例制定最佳安排。现在我们有几个主要级别的框架实用程序、应用程序对象、UI 框架、命令、UI 控制器和 EXE。除了 EXE（手动测试）之外，每个级别都有一个程序集。当我们编辑一个程序集时，我们会加载该级别的测试程序集。当我们需要做一些涉及每个级别的事情时，我们必须加载所有测试程序集。
在我们的一键构建过程中，我们运行测试项目 exe。 （为此我们有一个单独的实用程序）。
【讨论】：