Proposal/Discussion: Automatic Interfaces

[lemonlion]

There's a common pattern where class interfaces end up being created for the sole purpose of mocking in unit testing. This ends up creating a lot of boilerplate code as no actual alternative implementation is ever intended beyond the mock in the unit tests. These unit test-only interfaces must then be maintained every time there is a change to the class.

I propose a solution to this where a "default" interface can be defined and generated.

So for example this:

public class DependencyClass
{
	public void SomeMethod()
        // ...and many other methods/properties etc
}

public class ExampleClass
{
	private readonly I<<DependencyClass>> myContructorParameter;

	public ExampleClass(I<<DependencyClass>> myContructorParameter)
	{
		myConstructorParameter = _myContructorParameter;
	}
}

public class UnitTestsForExampleClass
{
	private readonly ExampleClass _serviceUnderTest;

	public UnitTestsForExampleClass()
	{
                var _dependency = new Mock.Of<I<<DependencyClass>>>();
		_serviceUnderTest = new ExampleClass(_dependency);
	}
}

Would be similar to

public interface IDependencyClass
{
	void SomeMethod()
        // ...and many other methods/properties etc
}

public class DependencyClass : IDependencyClass
{
	public void SomeMethod()
        // ...and many other methods/properties etc
}

public class ExampleClass
{
	private readonly IDependencyClass myContructorParameter;

	public ExampleClass(IDependencyClass myContructorParameter)
	{
		myConstructorParameter = _myContructorParameter;
	}
}

public class UnitTestsForExampleClass
{
	private readonly ExampleClass _serviceUnderTest;

	public UnitTestsForExampleClass()
	{
                var _dependency = new Mock.Of<IDependencyClass>();
		_serviceUnderTest = new ExampleClass(_dependency);
	}
}

I used the double bracket syntax (I<<ClassName>>) to distinguish it from a generic of a class called 'I', but completely open to syntax suggestions.

As far as I see it, this could be implemented in one of two ways:

1. High level, making it a kind of syntactic sugar. The code would be automatically/invisibly translated at compile time (similarly to the way that extension methods get converted into static classes in c# 7 and below). The disadvantage of this would be that you would only be able to use this syntax on classes that are created by you in your solution as you can't force an interface onto an external class. This would however still be an advantage over the current state of autogenerating interfaces using VS/Resharper and then having to maintain them.

2. Low level. Make all c# classes implement a default interface of themselves, only accessible via the "default interface" syntax (eg I<<ClassName>>). This would allow this syntax to be used on all classes that have been compiled from the correct version of c# upwards.

Please note, in my proposal, the interface I<<DependencyClass>> would/should be separate to an interface created by the user called IDependencyClass. ie there would/should be no namespace conflicts to creating an interface called IDependencyClass as well.

[HaloFour]

You could also just declare the methods of the class as virtual so that you can mock their behavior without having to declare an interface.

[lemonlion]

You could also just declare the methods of the class as virtual so that you can mock their behavior without having to declare an interface.

True. But doesn't virtual give the implication that subclasses are supposed to overwrite it's behaviour? Also, the second low level implementation of the proposal would allow you to do this with external classes for which their methods might not have been made virtual. The normal solution would be to create a wrapper class around them and Mock that instead, but again, more boilerplate code.

Edit: Also, that methodology is strongly criticised here - https://stackoverflow.com/questions/14451325/should-i-mark-all-methods-virtual

[jnm2]

I think this is a duplicate of #1231 and overlaps #245, so the discussion in both is relevant.

[Joe4evr]

But doesn't virtual give the implication that subclasses are supposed to override its behavior?

No, it only signals that subclasses are allowed to override the behavior. If they don't want to, they don't need to.

[lemonlion]

No, it only signals that subclasses are allowed to override the behavior. If they don't want to, they don't need to.

Resharper by default will give you warnings about it if you're not overwriting it anywhere, hence I have the impression some people think otherwise

[lemonlion]

You could also just declare the methods of the class as virtual so that you can mock their behavior without having to declare an interface.

Can I just ask if this is the optimal solution to this problem, why does everyone seem against it? See the following stack overflow:

https://stackoverflow.com/questions/14451325/should-i-mark-all-methods-virtual

I believe having automatic interfaces would sidestep the issues they have with virtual methods everywhere.

[jnm2]

In my experience, either option leads to really poor design. Interfaces exist to serve the needs of the client (consuming) code, and should live with the client; their definition should never be driven by the implementing class.
It seems inevitable to me that inferring an interface from a class will lead to blind design-by-accident.

[lemonlion]

In my experience, either option leads to really poor design. Interfaces exist to serve the needs of the client (consuming) code, and should live with the client; their definition should never be driven by the implementing class.
It seems inevitable to me that inferring an interface from a class will inevitably lead to blind design-by-accident.

When you say both options, which two are you referring to? Automatic interfaces and virtual methods everywhere? What would you suggest then, always using interfaces everywhere and accept the large boilerplate code/maintenance time hit?

[lemonlion]

Someone has suggested using delegates for all your dependencies as an alternative, but that doesn't seem to be a common/generally recommended solution to the problem

[Joe4evr]

Resharper by default will give you warnings about it if you're not overwriting it anywhere

Hot take: Resharper is bad.

[bondsbw]

I think this is the problem:

There's a common pattern where class interfaces end up being created for the sole purpose of mocking in unit testing.

It's the old pattern of testing an interface which has no reason to exist, other than to test the interface which has no reason to exist.

[jnm2]

When you say both options, which two are you referring to? Automatic interfaces and virtual methods everywhere? What would you suggest then, always using interfaces everywhere and accept the large boilerplate code/maintenance time hit?

Yes, those were the two. I would use tooling to extract an interface, put thought into each interface to keep it client-focused which is usually not hard, and make sure it lives with the client and not the implementation (if it differs).

Two other experiences come to mind:

• People often assume that the 'unit' in unit testing is synonymous with 'class' when in fact a unit can comprise multiple classes and vice versa.
• I've seen enough that I put more stock in integration tests than unit tests, but whatever you do, test the boundaries you care about. If you're finding it painful to write as many interfaces as you are, you obviously don't have a reason to care about that boundary. So treat that collection of classes as an atomic system under test.

[lemonlion]

It's the old pattern of testing an interface which has no reason to exist, other than to test the interface which has no reason to exist.

Well the goal in this case is to test a class that depends on another class/interface while having as little boilerplate code as possible to maintain. The purpose is not to test the interface or dependent class itself. It comes down to wanting to mock things for unit tests and how to do that.

Solutions to how you do mocking of dependencies for unit tests so far have been:

1. Use hard coded interfaces for everything. This is the most flexible approach but ends up with a huge amount of boilerplate code to maintain.

2. Use virtual methods everywhere. This is highly criticised here: https://stackoverflow.com/questions/14451325/should-i-mark-all-methods-virtual

3. Auto-interfaces (a non existent feature), which were suggested in this original proposal and in issue Automatic interfaces instead of explicit interfaces? #1231 and Proposal: use interface keyword to automatically wrap concrete classes #245 . Most people in those forums seem to suggest either solution 1) or 2), although most commonly 2).

4. Using delegates for all your dependencies

5. Use interfaces but create less of them by grouping classes together in one test. Not sure if that will create less code though if you want the same amount of test code coverage.

[bondsbw]

I think unit testing with mocks is a bit overrated. At least the way I see it traditionally described.

In my opinion you have another option:

6. It's important to focus on reducing public API to the bare necessities, and only testing that. Mock external systems (file, database, network, etc.), and when these don't have sufficiently mockable interfaces, provide adapters/delegates.

"Unit" testing all depends on what you consider to be a unit. I don't think units are classes. Units are distinct systems which are fully contained and have little external dependency. If that describes your whole application, but you think it's too big to be a unit, then work on reducing dependencies.

I like units to be assemblies. (Actually I like them to be components but C#/.NET doesn't support that as a distinct concept.)

[lemonlion]

I think unit testing with mocks is a bit overrated. At least the way I see it traditionally described.

In my opinion you have another option:

It's important to focus on reducing public API to the bare necessities, and only testing that. Mock external systems (file, database, network, etc.), and when these don't have sufficiently mockable interfaces, provide adapters/delegates.
"Unit" testing all depends on what you consider to be a unit. I don't think units are classes. Units are distinct systems which are fully contained and have little external dependency. If that describes your whole application, but you think it's too big to be a unit, then work on reducing dependencies.

I like units to be assemblies. (Actually I like them to be components but C#/.NET doesn't support that as a distinct concept.)

Although that is an approach, I think ultimately you end up writing the same (or more likely more) tests to get the same level of code coverage. The difference I see is when you have 1024 possible combinations of inputs to test, the odds are much higher that you'll miss some combinations rather that testing 5 more granular units with 4 inputs each that combine to create the same number of combinations (4 x 4 x 4 x 4 x 4). And with this approach you've only had to write 20 tests instead of 1024. Then your integration tests check that those units are integrating successfully.

What is more likely to happen in your approach is that 100 out of the 1000 or so combinations of inputs will be tested and the system ends up being created quickly but with far more things that can potentially go wrong.

[bondsbw]

And with this approach you've only had to write 20 tests instead of 1024.

I don't see why there would be a difference. I would have made 4 tests per input either way, unless there is a dependency between the inputs. In that case:

• For the large unit, we would test the combinations that would cause different coverage
• For the small units, we would mock the conditions which would cause different coverage and provide the different mocks

The latter should yield the same total number of tests, assuming the same amount of coverage.

[theunrepentantgeek]

There are many ways to create seams that allow for pieces of an application to be tested in isolation. Interfaces are one; virtual methods are another; delegates and events are two more.

For the (IMHO rare) cases where these are insufficient, there are other ways. Microsoft Fakes is perhaps the best known.

I recently stumbled across Pose. Quoting from the project page:

Pose allows you to replace any .NET method (including static and non-virtual) with a delegate. It is similar to Microsoft Fakes but unlike it Pose is implemented entirely in managed code (Reflection Emit API). Everything occurs at runtime and in-memory, no unmanaged Profiling APIs and no file system pollution with re-written assemblies.

I haven't tried it myself, but it would be worth checking out.

[lemonlion]

I don't see why there would be a difference. I would have made 4 tests per input either way, unless there is a dependency between the inputs.

Yes, and there are often dependencies between units.

In that case:

For the large unit, we would test the combinations that would cause different coverage
For the small units, we would mock the conditions which would cause different coverage and provide the different mocks

Yes which is exactly what I've been talking about this whole thread, how to deal with mocking.

[Richiban]

@lemonlion I have a lot of sympathy for your position, since I spent literally years wishing for the same thing. Now I have come to two opinions about clean code that would make such a feature redundant:

1. A one-to-one mapping between interfaces and their implementations (i.e. each interface has only one implementer and each concrete type implements only one interface) is a design smell. As such I don't think it would be productive to add a language feature that actually encourages this scenario.

As you've already said we're forced into this scenario because of how we're doing unit testing, which brings me to my second point:

2. As others have said already, it's so much better to get away from this idea--when testing--that a 'unit' is a 'class' or a 'method'. You should be testing your code from the outside in (and therefore the majority of your types should be internal) and your 'unit' is actually a behaviour. This was the original idea behind TDD but, since the industry twisted 'TDD' into 'test every class and every method' it was necessary to come up with the name 'BDD' to describe the original concept.

[asyncawaitmvvm]

Hot take: Resharper is bad.

Fortunately VS2015 stole the few usable features. They should do that more often.

[yaakov-h]

uhh @YairHalberstadt @CyrusNajmabadi @333fred what is going on here?

[333fred]

We're attempting to convert this to a discussion. It is failing to do so 😅