.net 测试解决方案中的项目

在.NET中，您应该将单元测试项目与解决方案的其余部分放在一起吗？或者应该有一个包含所有测试项目的测试解决方案吗

我们的代码库解决方案中包含了所有的测试项目……看起来有点麻烦

---

你通常做什么？

我一直把它们作为解决方案的一部分，毕竟它们是解决方案的一部分。不过，对于查看项目的不同方法，您可以有多个解决方案，因此在某些情况下，您可能希望创建一个无测试解决方案。

在我们当前的项目中，我们决定将所有单元测试放在单独的项目中。应用程序代码和测试在同一个解决方案中，但至少我们可以构建（和部署）一个没有单元测试代码的版本

到目前为止，这样做的缺点是，有时您的单元测试无法到达应用程序代码的某些成员（受保护和内部），但这通常会让我们发现我们的设计可以改进

---

我想我应该指出一个类似的主题，在相同/相似的主题上有更多的答案。

我不使用.NET，但是当我开发任何类型的测试用例时，我会将它们与代码的其余部分隔离开来，这样我就可以在不进行测试的情况下部署应用程序。用户不需要，甚至不想要这些东西。

我们的测试代码不提供，但它们是整个解决方案的一部分。我们的构建者分离出测试组件和核心组件。从解决方案管理的角度来看，拥有140多个项目的解决方案似乎势不可挡

我们总是在同一个解决方案中使用单独的项目

---

这意味着我们可以确定（使用引用）单元测试代码也会测试我们的显式引用（而不是隐式地获取某些东西的可见性，因为它在同一个程序集中——例如“内部”）

查看项目的设计。如果它靠近MVC布局或它的替代方案之一，那么您应该有不同级别的不同程序集。为设计的每个级别制作一个测试部件

我们的测试项目通常代替创建EXE的项目运行。我们的EXE项目是一个薄壳，它将事件和信息传递给一个程序集，该程序集中充满了控制器类，大多数人将这些代码放入EXE项目中。这允许测试项目在90%的正常测试过程中假装为EXE

我们仍在为实际测试用例制定最佳安排。现在我们有几个主要级别的框架实用程序、应用程序对象、UI框架、命令、UI控制器和EXE。除了EXE（手动测试）之外，我们每个级别都有一个程序集。编辑程序集时，我们加载该级别的测试程序集。当我们需要做一些涉及每个级别的事情时，我们必须加载所有的测试组件

---

在我们的一键构建过程中，我们运行测试项目exe。（我们对此有一个单独的实用程序）。

通常，我将单元测试放在他们自己的项目中，并将集成测试放在应用程序解决方案中他们自己的项目中

---

在我工作的地方，我们正在考虑将web测试放在一个单独的解决方案中。我们计划与QA团队共享web测试创作，我们不希望这些测试成为构建责任

尝试InternalsVisibleToAttribute（目标程序集），然后您的单元测试可以访问内部成员。private需要使用反射进行破解，因此如果需要独立测试，我总是将其标记为内部。（我认为OP已经在按照您的建议进行操作，他想知道该解决方案应该有多个测试项目，还是应该有一个只包含测试项目的单独解决方案。）谢谢你给我指点内部可视属性！我们经历了这个过程，在某个时刻，我们将一个包含60多个项目的单一解决方案拆分为2或3个解决方案。测试项目和他们测试的应用程序代码仍然在同一个解决方案中。对我来说，这似乎是一个可靠的解决方案。鉴于你不使用.NET，你显然不理解“解决方案”的概念。将应用程序项目和测试项目放在同一个解决方案中并不意味着测试包含在您实际提供给最终用户的产品中。