摩尔和内部类
我们目前正在使用 Moles 来测试一些与第三方库交互的代码。该库没有很好地进行测试设置（因此需要摩尔），我遇到的问题是它们只公开公开一个抽象类。具体实现在第三方库内部。
我面临的问题是，当尝试创建公共类型的实例时，它向鼹鼠请求具体类型，但鼹鼠不会为这些类型生成鼹鼠对象，因为它们是内部的。
根据moles文档，公开内部的方法是在AssemblyInfo.cs文件中添加InternalsVisibleTo属性。然而，这是为了暴露我的程序集内部结构供鼹鼠使用，因为这些是已经创建程序集的第三方库，我不知道如何使这些内部结构可见，以便鼹鼠可以使用它们。
无论如何，对此的任何帮助都会很棒。我会满足于集成测试，这是唯一的解决方案，但希望不必走到那一步。
We are using Moles currently to test some code that interacts with a 3rd party library. The library was not setup for testing very well (hence the need for moles) and the issue that I am running into is that they only publicly expose a single abstract class. The concrete implementations are internal to the 3rd party library.
The issue I am facing is that when trying to create an instance of the public type it is requesting a concrete type from moles, but moles isn't generating moles objects for those types because they are internal.
Under the moles documentation the way to expose the internals is to add the InternalsVisibleTo attribute in the AssemblyInfo.cs file. However this is to expose my assembly internals for moles to use, since these are 3rd party libraries with already created assemblies I don't know how to go about making those internals visible so that moles can use them.
Anyways, any help on this would be great. I will settle for an integration test is that is the only solution, but hope to not have to go to that point.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我非常成功地使用的一种方法是为不可模拟的第三方类型推出我自己的代理类。例如，我想依赖于密封/静态/没有接口/等的类型
ThirdParty.Foo。相反，我创建了一个名为ThirdParty.Proxies的库，并向这个新库添加了具体类型Foo和接口IFoo。接口IFoo公开的成员相当于我从底层ThirdParty.Foo类型和具体类型ThirdParty.Proxies.Foo实现中需要的所有成员。这些成员除了将方法调用转发到底层第三方库之外什么也不做。ThirdParty.Proxies被排除在单元测试和代码覆盖率之外。在我的消费程序集中，我仅依赖于ThirdParty.Proxies，具体来说，我仅依赖于IFoo。这样我就可以轻松模拟这种依赖关系，并为我使用的程序集实现 100% 的代码覆盖率。这需要更多的工作，并且与 Moles 动态为您所做的类似，但是一旦完成，它就可以在任何地方重复使用，并且您的单元测试将更快，因为不会产生 Moles 的开销。
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.Foowhich is sealed/static/has no interface/etc. Instead, I create a library calledThirdParty.Proxiesand add a concrete typeFooand an interfaceIFooto this new library. The interfaceIFooexposes members equivalent to all those which I require from the underlyingThirdParty.Footype and the concrete typeThirdParty.Proxies.Fooimplements those members by doing nothing other than forwarding method calls to the underlying third party library.ThirdParty.Proxiesis excluded from unit testing and code coverage. In my consuming assembly, I take a dependeny only onThirdParty.Proxiesand, specifically, I only take a dependency onIFoo. 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.