Moles and inner classes

We are currently using Moles to test code that interacts with a third-party library. The library was not set up for testing very well (hence the need for moles), and the problem I am faced with is that they only publish one abstract class in public. Specific implementations are internal to a third-party library.

The problem that I am facing is that when I try to create an instance of a public type, it requests a specific type from among the moles, but the mole does not generate mole objects for these types, because they are internal.

In the parenting documentation, a way to identify internal elements is to add the InternalsVisibleTo attribute to the AssemblyInfo.cs file. However, this is to expose my internal assembly elements to use moles, as these are third-party libraries with already created assemblies. I do not know how to make their insides visible so that the moth can use them.

In any case, any help would be wonderful. I agree to the integration test, this is the only solution, but I hope that you do not have to go to this issue.

+1
source share
1 answer

The approach that I have used very successfully is to collapse my own proxy classes for unrelated third-party types. For instance. I want to depend on the type of ThirdParty.Foo , which is sealed / static / has no interface / etc. Instead, I create a library called ThirdParty.Proxies and add the specific Foo type and IFoo interface to this new library. The IFoo interface provides members, equivalent to all those I need, from the base type ThirdParty.Foo , and the specific type ThirdParty.Proxies.Foo implements these elements without doing anything except calling the transfer method to the third-party base library. ThirdParty.Proxies excluded from unit testing and code coverage. In my consumer build, I only take dependency on ThirdParty.Proxies and, in particular, I take the dependency on IFoo . This way, I can easily mock this dependency and get 100% code coverage for my build assembly.

This is a little more work, and it looks like what Moles does dynamically for you, but once it is done, it can be reused everywhere and your unit tests will be faster if you do not incur Moles overhead.

+5
source

Source: https://habr.com/ru/post/905390/


All Articles