是否有可以测试非程序集（DLL）的.NET单元测试框架？

Question

我已经使用NUnit多年了，但是一直很恼火，你被迫将所有可测试的函数移动到一个单独的程序集（DLL），以便你可以对它们进行编写/运行测试。例如，我有一个Windows窗体项目（我在这个例子中使用MyProgram），它有几个我想测试的类。使用NUnit，您必须将这些类提取到另一个程序集（DLL）项目中，以便可以运行测试。所以我的项目，过去只包含一个项目MyProgram，现在需要3个项目：

1. MyProgram（Windows窗体应用程序）
2. MyProgramLib（要进行单元测试的装配，是MyProgram的一部分）
3. MyTestLib（NUnit测试程序集）

您可能会问为什么这是一个问题。我有几个原因：

1. 构建复杂性：现在我需要在项目中创建并测试新程序集。
2. 开发速度：开发人员需要一段时间才能切换到另一个项目来添加/编辑在主应用程序中更具逻辑意义的方法。
3. 难以管理：管理代码很困难。开发人员最终编写的方法非常冗长且冗长，以描述代码试图实现的具体内容。

我知道测试就像Java和Maven一样。我可以编写单元测试，我不需要创建MyProgramLib项目。

任何其他.NET单元测试框架（xUnit，MSTest，MbUnit等）是否支持编写测试而没有MyProgramLib要求？

Answer 1

使用NUnit来测试exe项目以及dll是非常有可能的。 .Net中的exe与dll实际上没什么不同，可以从exe或dll项目中引用exe。这意味着您可以创建一个NUnit项目，让它引用exe并根据exe

中定义的类型编写单元测试

Answer 2

恕我直言

• 构建复杂性：可能有点。你添加了另一个移动部件。
• Dev Speed - 切换到lib项目，而不是切换到exe项目。
• 差异管理..与此分区方案无关。似乎是一种意识或技能问题。

该模式是由于历史上您无法仅引用可执行文件库这一事实。它在某种程度上也是有道理的;应用程序和测试需要使用/共享生产代码（库），因此我们将其移动到一个共同的项目。这实际上是一个命名模式Humble Executable。

Answer 3

  

我已经使用了NUnit多年，但一直很恼火，你被迫将所有可测试的函数移动到一个单独的程序集（DLL），以便你可以在它们上面编写/运行测试。

正如其他人所说，NUnit加载程序集，而不是DLL。 Exes也是程序集，如果将程序集加载到测试运行器中，任何公开可见的[TestFixture]都将显示在NUnit中。

  

您可能会问为什么这是一个问题。我有几个原因：

     

  
• 构建复杂性：现在我需要在项目中创建并测试新程序集。
  

如果您考虑整个项目生命周期，那么这可能会改变您解决问题的方式。

例如，您可以根据版本和单独发布的内容，或者根据部署和单独测试的内容来考虑程序集。

如果你可以说“它只是一个用户界面修复，我只需要重新部署就是网站”，或者“我在这个程序集中进行了更改。我可以简单地为这个和相关的程序集添加单元和集成测试，并运行这个区域的回归测试“你在一个好位置。

如果你必须说“我必须重新部署整个应用程序”或“我必须重新运行我们的整个回归套件”，那么你就会遇到麻烦。

  

  
• 开发速度：开发人员需要一段时间才能切换到另一个项目来添加/编辑在主应用程序中更具逻辑意义的方法。
  

也许问题是你认为你有一个“主要应用程序”。

如果你正在编写一个与控制之外的服务器通信的应用程序，并且唯一的部分是瘦UI，那么这是有道理的。但即使在那里，你可能也有一些抽象和潜在的跨项目概念应该分开。

如果你使这种分离更加明显，那么无论装配数量多少，开发人员都能够快速导航。

  

  
• 难以管理：管理代码很困难。开发人员最终编写的方法非常冗长且冗长，以描述代码试图实现的具体内容。
  

这实际上是一个单独的问题。最好在不考虑装配的情况下进行管理。

听起来你应该更多地使用软件设计。 Single Responsibility Principle和其他SOLID OO原则将在这里帮助您，而不是担心程序集。

我发现，当它们不仅仅是大量的代码时，通常更容易导航大量的程序集。当它很好地映射到我们正在编写的软件时，该部门实际上有所帮助。但话说回来，我在过去的五年里一直陷入.Net，所以YMMV：）