Unit-testing – Is testing behavior of many classes in one test still unit testing

integration-testsunit testing

Our project's policy is to write unit tests for single classes only. All dependencies are mocked. Recently we've noticed that this approach makes us vulnerable in such cases:

Originally class A looks like this:

class A(val b: B) {

   fun doSomething() {
       b.doSomethingElse()
       b.doSomethingElse2()
   }
}

And such class A is covered with unit tests. Then due to new requirements class B goes through refactoring and gets hidden behind an interface so that it is technically possible that class A gets a different behavior based on a scenario.

The problem is that now, when we want to follow our project's guidelines, we also should refactor A's unit tests. Previously there was a test for proper communication with an object of B (mocked of course). Now when reference to B is gone then the test is refactored to verify communication with this new interface.

I find this scenario as an information loss happening during this test refactoring. We are no longer verifying any communication between A->B due to unit test purity when in real system such communication exists.

Having that in mind, should we change our way of thinking about unit tests and create test cases where there is more than one real object? Would it still be unit testing or is it already integration testing?

Best Answer

The outer limit of a unit is IO. If you're talking to peripheral's you ain't unit testing no more.

But within that you can carve things up as thickly or as finely as you see fit.

A test can exercise methods from three objects and still be a unit test. Some may claim that's integration but three lines of code are just as "integrated" so that's not really a thing. Method and object boundaries don't present any significant barrier to testing. Peripheral's do.

A test is not a unit test if:

It talks to the database

It communicates across the network

It touches the file system

It can't run at the same time as any of your other unit tests

You have to do special things to your environment (such as editing config files) to run it.

Michael Feathers - Working Effectively with Legacy Code

Now sure, you can argue that some people consider every test that can be automated by a unit testing frame work a unit test.

If we just want to argue semantics then fine, I'll define a unit as a beautiful flower in a field that smells bad.

Regardless of the terms, what is needed is segregation of slow troublesome tests from tests so blindingly fast and stable that you can run them while you type.

Call what they act on what you will. Just don't mix them up.

Related Solutions

C++ – Unit testing C++: What to test

Well, Unit Testing is only one part. Integration tests help you with the problem of your team. Integration Tests can be written for all kinds of applications, also for native and OpenGL applications. You should check out "Growing Object Oriented Software Guided by Tests" by Steve Freemann and Nat Pryce (e.g. http://www.amazon.com/Growing-Object-Oriented-Software-Guided-Signature/dp/0321503627). It leads you step by step through the development of an application with GUI and network communication.

Testing Software that was not test driven is another story. Check Michael Feathers "Working Effectively with Legacy Code" (http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052).

C# – Unit-Testing functions which have parameters of classes where source code is not accessible

What you are looking for is the adapter pattern: http://www.dofactory.com/Patterns/PatternAdapter.aspx

Using this pattern you can create a wrapper around the external class.

Lets take the following external class:

public sealed class SomeExternalClassWithoutInterface
{
    private readonly string _someValue;

    public SomeExternalClassWithoutInterface(string someConstructorValue)
    {
        _someValue = someConstructorValue;
    }
    public string Method1()
    {
        return _someValue;
    }

    public int Method2()
    {
        return _someValue.Length;
    }
}

We can now easily create our own class as a wrapper around this external class, and Implement an interface:

public class ExternalClassAdapter : IExternalClassAdapter
{
private readonly SomeExternalClassWithoutInterface _someExternalClassWithoutInterface;

// DI implementation, this is not neccesary
public ExternalClassAdapter(SomeExternalClassWithoutInterface someExternalClassWithoutInterface)
{
    _someExternalClassWithoutInterface = someExternalClassWithoutInterface;
}

// Constructor Without Depedency Injection, this is not preferable.
public ExternalClassAdapter(string someValue)
{
   _someExternalClassWithoutInterface = new SomeExternalClassWithoutInterface(someValue);
}

public string Method1()
{
    return _someExternalClassWithoutInterface.Method1();
}

public int Method2()
{
    return _someExternalClassWithoutInterface.Method2();
}

}

This is our interface, which is implementing all the methods used in the external class. (If alot of methods are available, seperate the interfaces according to the Interface Segregation principle)

public interface IExternalClassAdapter
    {
        string Method1();
        int Method2();
    }

Now, when this Adapter class is used in your application instead of the external class, you should be able to mock any other implementation pretty easy.

You should never use non interfaced external classes in your code.

Pastebin link (since the code outlining is not working well here): http://pastebin.com/2qN7u3u6

If, for any reason, you also need a facade pattern... You can still wrap these 2 adapters in a single facade! But do not create a single facade on 2 external classes!

Best Answer

Related Solutions

C++ – Unit testing C++: What to test

C# – Unit-Testing functions which have parameters of classes where source code is not accessible

Related Topic