我们目前正在使用 Moles 来测试一些与第三方库交互的代码。该库没有很好地进行测试（因此需要痣），我遇到的问题是它们只公开公开一个抽象类。具体实现在 3rd 方库内部。
我面临的问题是，当尝试创建公共类型的实例时，它会从 moles 请求具体类型，但 moles 不会为这些类型生成 moles 对象，因为它们是内部的。
在 moles 文档下，公开内部结构的方法是在 AssemblyInfo.cs 文件中添加 InternalsVisibleTo 属性。然而，这是为了让鼹鼠使用我的程序集内部，因为这些是已经创建程序集的 3rd 方库，我不知道如何使这些内部可见，以便鼹鼠可以使用它们。
无论如何，这方面的任何帮助都会很棒。我会接受集成测试，这是唯一的解决方案，但希望不必走到那一步。
An approach I've used very successfully is to roll my own proxy classes for unmockable third party types. E.g. I want to take a dependency on a type ThirdParty.Foo which is sealed/static/has no interface/etc. Instead, I create a library called ThirdParty.Proxies and add a concrete type Foo and an interface IFoo to this new library. The interface IFoo exposes members equivalent to all those which I require from the underlying ThirdParty.Foo type and the concrete type ThirdParty.Proxies.Foo implements those members by doing nothing other than forwarding method calls to the underlying third party library. ThirdParty.Proxies is excluded from unit testing and code coverage. In my consuming assembly, I take a dependeny only on ThirdParty.Proxies and, specifically, I only take a dependency on IFoo. This way I can mock this dependency easily and attain 100% code coverage for my consuming assembly.
This is a little more work, and it's similar to what Moles does for you dynamically, but once done it can be re-used everywhere and your unit tests will be faster by not incurring the overhead of Moles.