How to unit test without mocks and not be tied to a concrete implementations of an interface

Question

I consider myself to be a 'mockist' on the 'mockist' vs 'classicist' debate, but I am trying to understand the other point of view.

Imagine I have this class, where a concrete instance of IDependency is injected by an IoC container.

IDependency does not access a remote resource like a database or web service (in which case I would definately mock it), it is just another class containing some business logic.

public class UnitUnderTest
{
    public UnitUnderTest ( IDependency dependency )
    {
    }
}

Using this pattern, I am free to change the concrete implementation of IDependency by changing the class injected by the IoC container. I am not tied to any particular implementation.

If I was to test this class without mocking IDependency, wouldn't I have to instantiate my real IDependency to pass in to the constructor?

public class My_Unit_Test()
{
    IDependency concreteDependency = new ConcreteDependency();
    var unitUnderTest = new UnitUnderTest(concreteDependency);
}

In this example, if I write a replacement to ConcreteDependency, I would have to not only change my IoC container configuration, but all of my unit tests that use ConcreteDependency.

Or.. do I use the same IoC container within my unit tests (which seems like it goes against the idea of testing things in isolation)?

Answer 1

If I was to test this class without mocking IDependency, wouldn't I have to instantiate my real IDependency to pass in to the constructor?

No, you could create a fake IDependency for your specific needs. You may even make your "real" IDependency but parameterize it specifically to your needs. Though depending on who you talk to, these are considered mock objects since they're not used in production.

This is the common argument against mocking everything: you already have objects to do this stuff that are robust, flexible and trustworthy. You don't mock IList in your tests because List is a dependency do you?

Like most arguments, the best approach is often a balance of the two.

In this example, if I write a replacement to ConcreteDependency, I would have to not only change my IoC container configuration, but all of my unit tests that use ConcreteDependency.

Yes, just like you'd have to change all of your mocks should you replace your mock objects.

How to unit test without mocks and not be tied to a concrete implementations of an interface

You literally can not.

You need to create a concrete implementation of that interface somewhere. You could share that instance between tests, but that is against best practice (tests are not isolated). You could have a factory to generate the object, but then you have added complexity and it's uncommon that a single type of instance can be used for every test. But in the end, the test needs a concrete implementation to work, no matter how much indirection you put between the test and the thing.

Answer 2

You only need an IoC container if you want to centralize your dependency declarations. For everything else, there's ordinary constructor injection.

To put it another way, you don't need an IoC container in your unit tests. You're not testing the IoC container, after all.

To put it still another way, if you're stitching together a bunch of mock dependencies in your unit tests using an IoC container, they're no longer unit tests; they're integration tests (mock integration tests, if there is such a thing).