How to unit test that the correct implementation of an interface is used?

I have this problem with unit testing for years. Unit testing should test isolated units, that is, if we use interface/implementation vocabulary, it should test concrete implementation classes. Fine, let’s do it. In a code that is the client of the interface, one should mock the interface to suit the tests. That’s OK, let us do it where possible, too.

But then, in the productions code, there is some place where the actual implementation class is instantiated and used as the-instance-that-implements the interface. It may be factory methods, it can be somewhere else.

I have the problem how to actually test this glue between those two, correctly tested in isolation, layers. Using variants of instance of is brittle – not to say, the creator of the actual instance may be “smart” and choose different implementation based on circumstances. Even if not, it creates that instance using some configuration around.

So far, I either do not unit test in strict manner (so I do not do new Foo(directa, directb), but createApp(indirectA, indirectB).getFoo() instead), but that may not be proper unit testing. That does not test all the implementations, that test those-implementations-app-uses. Other approach I may see is to make tests of Foo implementation parametric, having a factory method makeFoo(a,b) and create subclasses for each implementations as well as one which creates those instances via an actual app.

Do you know of a good way on how to approach this?

In other words, the question may be simply “How to (unit) test glue code?”

The way you test glue code is by running an integration test.

The purpose of integration testing is to verify functional, performance, and reliability requirements placed on major design items. These “design items”, i.e. assemblages (or groups of units), are exercised through their interfaces using black box testing, success and error cases being simulated via appropriate parameter and data inputs.

Simulated usage of shared data areas and inter-process communication is tested and individual subsystems are exercised through their input interface. Test cases are constructed to test whether all the components within assemblages interact correctly, for example across procedure calls or process activations, and this is done after testing individual modules, i.e. unit testing.

There are two ways of writing unit tests. Most people think there’s only one way. If you use sociable tests, you can test the glue as part of the test.

In an aftermath of https://vimeo.com/80533536 talk of @jbrains, posted by @ThomasRuiz, I came to this conclusion:

Write contract tests (the talk has strict definition of them, I have loose one: “tests that only use public API of the class”).
Stop using new FooImpl(fooConfig) to create implementations of “instance that fulfills Foo contract”, instead, make it mandatory for your code to have createFoo(fooConfig) factory method to instantiate the Foo contract worker (maybe it should be called hireFoo 😉 ).
Your contract tests should test against client.createFoo(testFooConfig). It may be you end up with the need of client being higherClient.createBar(...) itself. This is the weak spot of the whole thing. Maybe I should ask.jbrains.ca … :-

EDIT: Talked with @jbrains. The result is:

Your constructors should not create the collaborators. Ideally, they get them injected, like new Foo(collab1, collab2);
Applying this to the extreme, it ends up with creating all (!!!) collaborators up front in the topmost layer. See http://blog.thecodewhisperer.com/2011/12/07/refactor-your-way-to-a-dependency-injection-container. See it as an app config.
Citation “new A(new B(new E()), new C(new F(), new G()), new D()) is fine. A creating B, which creates E (and so on) causes problems”, in https://twitter.com/jbrains/status/570974691013337089.

I finally know what actual dependency injection is and why it is important (your code becomes actually testable and decoupled, all the glue code is in one place and is the only untested piece).

But then, in the productions code, there is some place where the actual implementation class is instantiated and used as the-instance-that-implements the interface. It may be factory methods, it can be somewhere else.

How do you test that?

There are three scenarios here.

The first is that you don’t care about the instance used. Some code internally uses some concrete instance to do its work and that code is already “unit” sized. That’s great. Ignore the implementation detail and test the inputs/outputs.

The second is some sort of factory. For some given inputs, you get the proper output. That is an easy to test unit like any other unit – provide some inputs (tending towards boundary conditions) and make sure the output is correct. Usually instanceof is sufficient, but you could check behavior of the resultant object if it’s simple/obvious/unchanging.

The third is configuration sort of code. It might be configuration itself, or it might be hardcoded inputs to more general code. In almost all of my apps for example, all main does is specify concrete instances and glue them together. I do not unit test that code, and I do not recommend you do either.

Why? Because it provides no benefit. Unit testing exists to provide early, clear signs that something is wrong. In my experience, if you screwed up your concrete instantiation (and have a relatively sane architecture) then simply running the app provides a quick, clear and cheap indicator if things are configured correctly or not.

Filed under: softwareengineering - @ 18:25

Thẻ: unit-testing

Thiết kế website giá rẻ

Danh mục

How to unit test that the correct implementation of an interface is used?