对内部维护单例状态的第三方库进行自动测试
我的代码使用的是第三方库，它在内部深处采用了单例模式。在第一次访问时，库使用windows环境变量来标识从其中加载它的配置文件夹。
但是，我想在不同的单元测试集合中针对不同的文件夹运行。理想情况下，我应该为每个单元测试类或somesuch指定配置文件夹。
第三方库是一个巨大的对象模型，我的代码只是它们之上的一组扩展方法。我看不出有什么容易的办法来嘲弄整个图书馆。
有任何方法可以为每个测试类创建一个新的appdomain吗？我知道负载测试具有在运行测试程序集之间创建域的设置。在我的例子中，这将是很多程序集，我不太确定是否/如何在单元测试测试器上设置这个设置。
或者，我正在考虑购买Typemock Isolator或JustMock，这样我就可以使单例返回一个"null"，从而导致第三方库加载一个新的库。我已经看过反编译代码，看起来它可以达到预期的结果。当然，这里可能隐藏着更多的“好东西”。
这些都是人为的方法。我真正想要的是“刷新”测试、测试类或测试程序集之间的完整应用程序域。
当自动测试需要切换配置文件夹时，我愿意牺牲速度。红绿重构循环可能不会包括多个配置文件夹。
对于如何做到这一点，有什么建议吗？
编辑--我刚刚发现不同的测试程序集会导致删除单个程序集。因此，可以根据运行测试程序集的配置来组织测试程序集，而不是按照测试所针对的依赖关系或问题域来组织。
回答 2
Stack Overflow用户
发布于 2012-01-08 10:44:15
在不同的测试程序集中展开。
将单元测试类扩展到不同的测试程序集将导致由测试者创建新的appdomains，因此将擦除单个程序集。因此，可以根据运行测试程序集的配置来组织测试程序集，而不是按照测试所针对的依赖关系或问题域来组织。
但是，这个解决方案可能并不适合每个人，原因如下：
这有可能创建一个混乱的解决方案，有大量的测试项目(针对各种测试数据)。由此产生的结构与按组件和问题域组织单元测试的标准实践背道而驰。
我没有触及单身人士的数据。它只是一个支持数据引用库。单元测试的主要指令是它们之间不应相互影响，也不需要特定的序列。
单元测试的另一个主要指令是它们必须运行得很快。幸运的是，我将不必在普通的红色->绿色->重构周期中运行多个测试配置。测试程序集的更大套件是回归测试。
Stack Overflow用户
发布于 2012-01-08 17:11:35
如果要进行真正的单元测试(而不是集成测试等)，我建议包装外部依赖项。
我看不出有什么容易的办法来嘲弄整个图书馆。
看一看立面图案。您提到了它有一个庞大的对象模型；很可能您的代码正在与其中的一小部分交互。考虑将facade声明化，因为它的方法描述了您想要完成的任务，而不是如何完成任务。该外观不一定是通用的，它只需要为您的应用程序工作。
确保您的facade实现了一个或多个接口。通常，您希望一个或多个工厂返回具体实现的实例。
其余的代码只使用facade。应该只在一个地方调用工厂(或者您可以添加工厂接口)；其他一切都是通过依赖注入完成的。
要单元测试类的其余部分(除了facade之外的所有内容)，您可以注入模拟对象。
包装器代码应该是一个非常薄的层。您仍然希望通过实际的库对其进行集成测试。
https://stackoverflow.com/questions/8776485
复制相似问题
腾讯云开发者
