痣和内部类 [英] Moles and internal classes

问题描述

我们使用的是鼹鼠目前测试一些code，与第三方库交互。该存储库尚未安装用于测试非常好（因此需要摩尔），而我遇到的问题是，他们只公开公开一个抽象类。具体实现是内部的第三方库。

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.

根据摩尔文档以暴露内部的方式是添加InternalsVisibleTo属性中AssemblyInfo.cs文件。然而，这是揭露我总成内部的痣使用，因为这些第三方库在已创建组件，我不知道如何去制造这些内部可见，以便痣可以使用它们。

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.

推荐答案

我已经非常成功的推出自己的代理类unmockable第三方类型的方法。例如。我想采取一种 ThirdParty.Foo 这是封/静态的依赖/没有接口/等。相反，我创建了一个名为库 ThirdParty.Proxies 并添加一个具体类型富和接口的IFoo 这个新库。接口的IFoo 公开成员等同于所有那些我需要从底层 ThirdParty.Foo 类型和具体类型 ThirdParty.Proxies.Foo 实施这些成员所做的仅仅是转发方法调用底层的第三方库等。 ThirdParty.Proxies 被排除在单元测试和code覆盖。在我的组装费，我拿dependeny只在 ThirdParty.Proxies ，具体而言，我只对的IFoo 。这样我可以很容易地嘲笑这种依赖关系，达到100％code覆盖我的消费组装。

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.

这篇关于痣和内部类的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！