Picture by Olivander Some rights reserved.

Having introduced mock objects, even if you’ve managed to avoid the pitfalls described in the previous posts in this series, you can often end up with some pretty complex and ugly-looking unit tests. There might be a lot of mock objects doing very little or there may be a lot of configuration required for the test. Fight the urge to blame the unit test though. If the unit test is complex, chances are it’s because the underlying code is complex.

For example, you might find yourself creating multiple mock objects simply to reproduce this pattern;

    classA.getB().getC().getD().doSomethingWithD();

In order to mock the invocation of the class D method you end up with something that looks like this if you’re using EasyMock:

    A mockA = createMock(A.class);
    B mockB = createMock(B.class);
    C mockC = createMock(C.class);
    D mockD = createMock(D.class);

    expect(mockA.getB()).andReturn(mockB);
    expect(mockB.getC()).andReturn(mockC);
    expect(mockC.getD()).andReturn(mockD);
    expect(mockD.doSomethingWithD()).andReturn(true);

It gets worse if this pattern repeats itself throughout the code. If it does though it’s probably a code smell and more than likely indicates some potential refactoring of the underlying code. Apply the Remove Middle Man refactoring and go to this:

    classA.doSomething();    // Delegates to doSomethingWithD

The setup for your mock object in your unit test reduces to:

    A mockA = createMock(A.class);
    expect(mockA.doSomething()).andReturn(true);

Refactoring as you go while implementing your tests will help reduce this kind of complexity but be careful! Without a unit test in place for regression testing you may actually introduce bugs without realising it. The general rule for writing unit tests applies: get your test working, refactor the code a little, refactor the test a little and make sure nothing is broken.

Your best bet may be to get a working unit test regardless of how complex it is without any significant refactoring of the code under test and then refactor¹. This way you’ll have a test which can be used to do regression testing. Later you can refactor the code being tested and you’ll then be able to refactor the test, simplifying that too.

Having said all that be very aware that you may be overcomplicating your test with your use of mocks and may end up hiding the real test in a pile of mock object expectations. This is where the use of stubs as opposed to mocks can come in handy, especially if refactoring is not an option². Instead of creating a set of mock objects and setting up their expected method calls, you create stub versions of the collaborator classes which have canned responses to method invocations. You might find that these can then be re-used throughout your tests, simplifying them greatly.

Using my previous example, we might create a stub version of A in the following way:

    public class StubA implements A {
        private B stubB;

        public StubA(B stubB) {
            this.stubB = stubB;
        }

        @Override
        public B getB() {
            return stubB;
        }

        // Other interface methods are implemented as well and
        // can either return dummy values or throw exceptions.
    }

This of course assumes that A is an interface or can be extended with all of it’s public methods being overridden. Don’t forget that the whole point of the exercise is to test code in isolation of the actual implementation of A. We just want our stub implementation to return dummy values or throw exceptions for methods we don’t want (or expect) to be called.

Assuming that the stub versions of B and C look something similar, the setup of our test now looks something like:

    // This is the only mock object - it's the
    // real thing we're looking to happen.
    D mockD = createMock(D.class);
    expect(mockD.doSomethingWithD()).andReturn(true);

    // Here come the stubs which just enable our test.
    A classA = new StubA(new StubB(new StubC(mockD))));

Now when the code under test does this…

    classA.getB().getC().getD().doSomethingWithD();

…our stubs will provide the mock object which will be invoked to do the real work.

The nice thing about this is that because we don’t care about how A, B and C get used we don’t have to create mock objects. On top of that, if these objects are used in the same way in multiple tests then my stub implementations can be re-used making the whole test suite a lot simpler.

I reckon it’s largely a judgement call on when to use mocks or stubs and it’s one that probably only really comes with experience³. In my mind though there’s nothing wrong with starting out with a complex unit test full of mock objects, refactoring the code and then refactoring the test to simplify it all, including replacing mock objects with stubs.

In the next part of this series I’ll show how complexity can also be a result of “engineered bugs”.

– Fintan

Picture by greefus groinks Some rights reserved.

In the previous part of this series on retrofitting unit tests I talked about how you can break the unit-test as integration-test pattern by introducing mock objects. Probably the best way to do this is by using one of the many mock object toolkits out there¹ . For Java development my preference is for EasyMock although there are plenty of others.

Introducing mock objects can cause their own set of headaches though and when retrofitting unit tests to existing code you’re likely to find a number of reasons why it can prove difficult or even impossible to introduce them.

The first and often hardest problem to get around is that the code to be tested is tightly-coupled with the dependency you’re trying to mock out. If class A uses an instance of class B it’ll be impossible to mock that instance if it’s constructed somewhere inside class A. You can get around this by doing a small amount of refactoring and introducing dependency injection but there could be the suspicion that you’re changing the design of your code to make it testable.

I really like dependency injection and inversion of control as general patterns but I realise that it’s something of a controversial subject. The arguments for and against it are summed up well in Martin Fowler’s excellent piece on the subject and there’s been an ongoing discussion on mockobjects.com about it’s use in unit testing as well. Some of the people I’ve spoken to who dislike DI feel that it breaks basic rules of encapsulation. Personally I think you need to strike a balance between encapsulation and tight-coupling between objects.

Assuming you’re coding to interfaces I see no reason why you can’t inject the implementation to be used without breaking encapsulation. If anything you’ll just be exposing your object’s contract with the rest of the system rather than how it works. To add a bit of DI while avoiding having to change the way the object is used throughout the code you could add a package-scope constructor that sets the mock instance required. By making it package-scope you’re limiting the scope for it to be used outside of the context of a unit test. The drawback is that you’re now adding code purely for testing and your test will be bypassing the constructor used at runtime.

One alternative solution to dependency injection when you need to break tightly-coupled dependencies in unit tests is to use Aspects. You could create an Aspect to intercept invocations on particular methods, creating a kind of pseudo-mock. This article on xprogramming.com has a good description of an implementation of mock objects using aspects. This isn’t something I’ve had a chance to try out but I suspect it has some drawbacks and any implementation may prove complex. If you try it out let me know how you get on.

Apart from tight-coupling between objects there are other problems you’ll come across when introducing mock objects while retrofitting unit tests in Java code. Static and final methods are the enemy of mock objects as are public properties, particularly with something like EasyMock. Statics and finals can’t be overridden and the mock object will have no control over access to public properties. If there are a lot of these in the code to be tested then it can cause problems for your mock objects.

Sometimes though these problems are code-smells and deserve to be refactored as you go. Public properties are the antithesis of encapsulation and direct access should be replaced with the use of getter and setter methods². Statics often indicate a laziness or poor understanding of object-oriented design while a lot of finals can often be a sign of premature optimisation.

You can get around some of these problems with a slight refactoring of the code under test. Refactoring as you go is part of the basic approach to writing a unit test anyway but when you’re working on existing code you need to do it carefully, especially if you have a limited understanding of what the code is doing in the first place. Your best bet is to write as much of the test as you can, refactor the code a little and write more of the test. Run the test each time you change something to make sure that you’re at least keeping the result of your test consistent with the previous result.

Finally, mock objects are great but not if you have to mock a complex data model. Remember that the purpose of a mock object is to model the behaviour of some external dependency without having it actually do anything. If you find that you’re creating mock object after mock object to model a set of beans you’re heading in the wrong direction. If a complex data model is required you’re better off having a test data model handy that can be dropped into the code under test, perhaps as the return value from a call to an object that is mocking the model’s container. Again there might be a code smell here if an object is essentially a container for some data but has a method that performs some transformation or operation on that data. There may be a case of divided responsibilities and a need to split the class in two.

In the next part of the series I’ll talk about how to react when, having broken your dependencies using mock objects, your new unit test looks hideously complex.

– Fintan

Picture by icathing Some rights reserved.

One of the most common mistakes I’ve found, particularly with teams who haven’t had a good deal of experience of unit testing or TDD, is that if they do have unit tests they’re often really integration tests with fake mustaches. A small, relatively self-contained piece of code needs a database with test data or a running ORB and server process otherwise the test “fails”.

The issue here is one of scope and the key word is “unit”. Typically this is a single class but could even be a single method in a class. A unit test should only test a single unit of code and not any of its external dependencies. If you’re writing a test to see if a particular Java class aggregates some data correctly prior to writing it to a database then you shouldn’t need a database to find out if it works or not. The test ends when the database is invoked with the correct (or incorrect!) data and the database is treated like a black box that just works.

The reasons for this are quite simple. If you are relying on a database and the test fails you’ll have no idea if it failed because of some problem in the code or in the database. You should be able to work this out, perhaps with a little digging, but false positives like this waste time and seriously reduce your confidence in the ability of unit tests to perform decent regression testing. Imagine having a test that ran in the past but now fails after you make a change to the code being tested. You have to figure out did it fail because of something you did or because the external dependency (e.g. the database) is broken or isn’t set up properly?

Another good reason is that your unit tests should run quickly. If it takes a long time to run all your tests as part of your build the inclination will be to avoid running them. Reducing the amount of execution time spent outside the code under test will help keep them quick. With Java projects I prefer to have the default Ant build target run my unit tests and have a separate “quick” build target to build without the tests. Apart from anything else it makes sure that I don’t forget to run my unit tests while I’m making changes and before I check any of those changes into source control.

Integration tests are important and if you have some masquerading as unit tests don’t bin them. You can do one of two things:

• Move them to a separate area and run them using a different test regime¹. Your unit tests have come out of the closet and are now proud integration tests. Now go off and write unit tests to replace them, being careful to avoid dragging in the external dependencies.
• Alternatively change the existing tests to decouple your external dependencies so that they don’t rely on them being in place to work. Drop the orb and the database and mock them.

Either way mock objects can be incredibly useful and I use them extensively in my tests. If you don’t know what mock objects are have a read of this great article by Martin Fowler and some of the more meaty posts on the Mock Objects blog. The basic idea is that you create a dummy version of the external component, set an expectation of how it should be used and behave but without it actually having to do any real work.

Treating external dependencies as black boxes like this is okay. Imagine you have a class A which uses class B and you have a passing unit test for class B. You can test class A with a mock class B and, if the test passes, can be highly confident that when you put A with a real B it’ll work. On top of that your unit test for class A will run quicker and be less brittle.

In the next part of this series I’ll talk a bit more about mock objects and the problems with introducing them when retrofitting unit tests.

– Fintan

Picture by hugovk Some rights reserved.

A while ago I promised to write a few articles on the art of test-driven development or TDD¹. Rather than starting with TDD itself I wanted to start by talking about what happens when you try to write unit tests after you write your code.

This can happen for any number of reasons. A team may want a suite of unit tests with good coverage but may not be willing or experienced enough to either try TDD or make it work. All too frequently a team that isn’t used to writing unit tests, or can’t get it’s collective head around how you can write a test for something that doesn’t exist yet, will usually revert to writing the test afterwards. The result is that unit tests drop down on the priority list and are the first thing to be cut when a project starts slipping.

This isn’t helped by the fact that the very word “test” implies something done after the fact². I’ve lost track of the number of interviews or conversations I’ve had where, when TDD comes up, I get a knowing look and the question “Did you really write your tests first?” as if it was okay, I was with friends and could admit that I just dive straight in and write the code first. No, I like to write my unit tests first. That’s why it’s called test-driven development.

As I’ve moved around in a couple of different jobs recently though I’ve found myself working on code with few³ unit tests. As a result I’ve picked up a lot of experience in retrofitting unit-tests to existing code. Over the next few weeks I’ll be sharing some of the experiences I’ve had and how I solved some of the problems that came up.

First up: when a unit test isn’t.

– Fintan