2

我的代码使用了一个第三方库，该库在其内部深处采用了单例模式。首次访问时，该库使用 Windows 环境变量来识别从中加载它的配置文件夹。

但是，我想在不同的单元测试集中针对不同的文件夹运行。理想情况下，我会为每个单元测试类或类似的东西指定配置文件夹。

第三方库是一个巨大的对象模型，我的代码只是在它们之上的一组扩展方法。我看不出模拟整个库的简单方法。

有什么方法可以为每个测试类创建一个新的 appdomain 吗？我知道负载测试具有在运行的测试程序集之间创建域的设置。就我而言，这将是很多程序集，我不太确定是否/如何在单元测试测试运行程序上设置此设置。

或者，我正在考虑购买 Typemock Isolator 或 JustMock，以便我可以使单例返回“null”，从而导致第 3 方库加载新库。我查看了反编译的代码，它似乎可以达到预期的结果。当然，那里可能隐藏着更多的“好东西”。

这些都是人为的方法。我真正想要的是在测试、测试类或测试程序集之间“刷新”完整的 appdomain。

当自动化测试需要切换配置文件夹时，我愿意牺牲速度。红绿重构周期可能不会包含多个配置文件夹。

关于如何实现这一目标的任何建议？

编辑 我刚刚发现不同的测试程序集会导致单例被擦除。因此，可以根据它们运行的​​配置来组织测试程序集，而不是根据测试所针对的依赖项或问题域来组织测试程序集。

4

2 回答 2

2

如果您要进行真正的单元测试（而不是集成测试等），我建议包装外部依赖项。

我看不出模拟整个库的简单方法。

看看Facade 模式。你提到它有一个巨大的对象模型；您的代码可能正在与其中的一小部分进行交互。考虑使外观具有声明性，因为它的方法描述了您要完成的工作，而不是如何完成。外观不必是通用的，它只需要为您的应用程序工作。

确保你的外观实现了一个或多个接口。通常，您会希望一个或多个工厂返回具体实现的实例。

您的所有其余代码仅使用外观。工厂应该只在一个地方调用（或者你可以添加工厂接口）；其他一切都是通过依赖注入完成的。

要对其余的类（除了外观）进行单元测试，您可以注入模拟对象。

您的包装代码应该是一个非常薄的层。您仍然需要针对实际库进行集成测试。

于 2012-01-08T17:11:35.153 回答
1

分散在不同的测试组件中。

将单元测试类传播到不同的测试程序集将导致测试运行者创建新的应用程序域，因此将删除单例。因此，可以根据它们运行的​​配置来组织测试程序集，而不是根据测试所针对的依赖项或问题域来组织测试程序集。

但是，由于以下原因，此解决方案可能并不适合所有人：

这有创建一个包含大量测试项目（针对各种测试数据）的混乱解决方案的危险。由此产生的结构与按组件和问题域组织单元测试的标准做法相反。

我没有触及单例中的数据。它只是一个支持数据参考库。单元测试的主要指令是它们不应相互影响或需要特定的顺序。

单元测试的另一个主要指令是它们应该运行得快。幸运的是，我不必在正常的 red->green->refactor 循环中针对多个测试配置运行。更大的测试程序集将是回归测试。

于 2012-01-08T10:44:15.740 回答