痣和内部类答案

【问题标题】：Moles and internal classes痣和内部类
【发布时间】：2023-03-07 23:41:01
【问题描述】：

我们目前正在使用 Moles 来测试一些与第三方库交互的代码。该库没有很好地进行测试（因此需要痣），我遇到的问题是它们只公开公开一个抽象类。具体实现在 3rd 方库内部。

我面临的问题是，当尝试创建公共类型的实例时，它会从 moles 请求具体类型，但 moles 不会为这些类型生成 moles 对象，因为它们是内部的。

在 moles 文档中，公开内部结构的方法是在 AssemblyInfo.cs 文件中添加 InternalsVisibleTo 属性。然而，这是为了让鼹鼠使用我的程序集内部，因为这些是已经创建程序集的 3rd 方库，我不知道如何使这些内部可见，以便鼹鼠可以使用它们。

无论如何，这方面的任何帮助都会很棒。我会接受集成测试，这是唯一的解决方案，但希望不必走到那一步。

【问题讨论】：

您的测试是否也需要涵盖对第 3 方库的测试？
不，我不直接关心 3rd 方库，这只是关心测试我使用 3rd 方工具的代码。

标签： c# .net unit-testing moles pex-and-moles

【解决方案1】：

我非常成功地使用的一种方法是为不可模拟的第三方类型滚动我自己的代理类。例如。我想依赖一个类型ThirdParty.Foo，它是密封的/静态的/没有接口/等。相反，我创建了一个名为 ThirdParty.Proxies 的库，并向这个新库添加了一个具体类型 Foo 和一个接口 IFoo。接口IFoo 公开了与我从底层ThirdParty.Foo 类型中需要的所有成员等效的成员，而具体类型ThirdParty.Proxies.Foo 通过将方法调用转发到底层第三方库之外什么都不做来实现这些成员。 ThirdParty.Proxies 被排除在单元测试和代码覆盖范围之外。在我的消费程序集中，我只依赖ThirdParty.Proxies，具体来说，我只依赖IFoo。这样我就可以轻松地模拟这种依赖关系，并为我的消费程序集实现 100% 的代码覆盖率。

这需要做更多的工作，它类似于 Moles 为您动态执行的操作，但一旦完成，它就可以在任何地方重复使用，并且您的单元测试会更快，因为不会产生 Moles 的开销。

【讨论】：

我也使用过这种方法。效果很好，可以解决您的问题。
我喜欢完全摆脱痣的想法，一件事是假设代理类本身（因为它们只是适配器）除了集成测试之外是不可测试的。我看到您说您没有在覆盖率计算中包含该代码，但这对您来说是个问题吗？
我们发现排除代理程序集是可以接受的。它们是非常简单的类型，仅由一行方法转发器组成，正如您所说，通过集成测试确保它们具有合理的覆盖率是很好的。代码审查通常也会找出任何小的错别字或错误。您会发现，一旦您编写了一些代理，就有 3 或 4 个用于编写它们的“公式”，具体取决于您的代理类型是密封/静态/等。你会非常有信心添加新的。事实上，到目前为止，我们从未在代理类型中发现错误。