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

_why has just released Hackety Hack, a starter kit for kids who want to learn to program. It’s Ruby and is aimed at kids 13 and over. As someone who got their first introduction to programming writing BASIC on an Apple II¹ many moons ago, I think this is incredibly cool. I was having a conversation with a friend of mine only the other day about how his kids have no interest in programming despite being highly computer literate. Hopefully this is something that will get them interested as they should be able to produce useful real applications really quickly.

Incidentally, I forgot to add that Matthew Hutchinson from the Ruby Ireland group pointed this one out. Cheers Matt!

– Fintan

Picture by colmmacc Some rights reserved.

Apparently An Taoiseach thinks that we’re the laughing stock of Europe for not rolling out eVoting (see this RTE News article). Hmm… I’m sure they’re having a good laugh at us in France right now where their Nedap voting machines, the same ones we currently have in warehouses, are causing problems.

As someone who has worked as a software developer for years eVoting is something that really bothers me. To be honest, I’m not that concerned about electoral fraud. It’s not like manual voting hasn’t been the subject of electoral fraud in past, but at least with a manual ballot count you can be pretty sure that it’s being done under the scrutiny of representatives of all parties¹. What I am concerned about is some script kiddie changing my vote to a vote for Senator Palpatine or some buggy, poorly written code that wasn’t tested properly due to budget or time constraints resulting in my vote being lost.

At least a piece of paper with a box on it won’t crash or forget what I voted for.

Incidentally, the picture of the Nedap machine above comes from Colm MacCárthaigh who has a small piece from last year here on how it was hacked.

– Fintan

BarCamp Dublin took place yesterday. It was my first BarCamp but certainly won’t be my last. It was a lot of fun and there was a great turnout. The venue in the Digital Exchange building, part of the Digital Hub in Dublin, was a good one but there were persistent internet connectivity problems throughout the day. The upside of that though was that there didn’t seem to be too many people spending all their time on Twitter¹ :-).

I had thought about writing an overview of each of the sessions I went to but there was just so much good stuff talked about that this post would have been far too long. Suffice to say that among the highlights was Conor Halpin’s talk about pricing models for SaaS, illustrated by his use of a straightjacket. He recommended a mixed model of subscription and per-usage charges. Darren Barefoot from Capulet had a session on social media marketing with some great tips on how to increase the audience for blogs and how to use bloggers for marketing products. Eoghan McCabe’s talk on web usability generated a great deal of audience discussion, surprisingly around a specific case: the way online banking sites ask for a customer’s PIN. Later Paul Campbell (pictured left), a member of the Ruby Ireland user group and along with Eoghan part of the new Patchwork team, gave a typically enthusiastic introduction to Rails, pulling off his first ever presentation really well.

After lunch there was a panel discussion on some general Web 2.0 issues with Tom Raftery, Sean O’Sullivan from Rococosoft who had earlier talked about Voice 2.0, Darren Barefoot and tech journalist Karlin Lillington. Among the questions the panel covered were how to make money from web 2.0 (advertising and a premium rate model like Flickr) and getting more readers for your blog (quality is more important than frequency; sincerity and originality is vital). There was also an interesting discussion on the recent death threats made to Kathy Sierra and the subsequent O’Reilly code of conduct kerfuffle. Darren Barefoot made an interesting observation about how the barrier of entry to fame has been lowered. The long tail effect is probably coming into play – it’s possible to become famous among a smaller niche group. Notoriety in any form tends to bring undesirable attention and that’s something that bloggers need to be aware of.

The final session I went to was a bit rushed unfortunately because previous sessions had overrun. There were also very few people at it which was a pity because Krishna De had some interesting things to say about using blogging to build buzz about your business. I look forward to being able to hear her speak again under better circumstances.

Afterwards it was down to the Lord Edward in Christchurch for a few free pints courtesy of Diageo. Overall the event was excellently organised, well supported by the various sponsors and attended by a group of interesting, passionate individuals. Hopefully next time internet connectivity will be sorted out.

– Fintan

Picture by CraigOppy Some rights reserved.

Something I’ve been meaning to comment on for quite a while now has been some of what I experienced a few months ago while hunting for a new job¹.

One of the thing that really got to me was the number of times I was asked to rate my various skills out of 10. At first I didn’t really have a problem with it but more and more I came to realise that rating yourself out of 10 just doesn’t make sense. It’s a completely subjective analysis of skills and does nothing to give a correct idea of your ability. What’s worse is that you’re are being asked to rate yourself on a scale that has been decided by someone else in advance without your knowledge. Here’s a quick case study.

Asked to rate my Java development skills out of 10, I gave myself an 8. This was based on what I felt was my ability related to people and code I had worked with and, more importantly, what I felt were my general OOD design skills. Relatively speaking I felt I was quite strong and rated myself in the top 10 to 20%. What I didn’t realise was that my interviewer took it to mean that I had an encyclopedic knowledge of the Java API and could, quite literally, write any code asked of me on a piece of paper without reference to Javadocs which is what he proceeded to do. Unfortunately this isn’t the case. Worst. Interview. Ever.²

I think the reality is that it’s impossible to rate yourself on any scale unless you are given some idea of what you’re rating yourself against. I also believe that a good developer can learn pretty much any language they need to use; it’s basic software design skills that are far more important and are much harder to rate out of 10. Being asked to rate yourself out of 10 is at best the sign of someone who just doesn’t understand the domain and at worst the sign of someone who is too lazy to read through a CV and talk to you to get an informed opinion of your ability. Quite apart from anything few people if any will rate themselves down³ so it becomes a fairly meaningless metric anyway.

The only way to be sure that someone knows their Visitors from their Acceptors is to ask them. If you want to know how much someone knows about Java ask them what the Object contract for hashCode() and equals() is. If it’s C++ ask them about virtual destructors and the risks of using auto_ptr. Ask them what books they’ve read and what blogs they read regularly. Get an idea of how they work not what they think of themselves. I’ve been on both sides of the interviewing table and so far I think I’ve done pretty well. Not wanting to bang my drum but *bang* *bang* so far I don’t think I’ve been responsible for recommending a hire who didn’t work out. And I never once asked them to rate their skills out of 10.

– Fintan

A former colleague of mine was recently trying to sort out a question in his head once and for all: which is better, declaring a variable inside a loop or outside of a loop? A Google search lead him to this thread on Javalobby and knowing my feelings on the subject he thought I’d find the comments interesting. I certainly did but I wasn’t surprised by some of what I read.

It’s to be expected that most conscientious developers will have one eye on performance while writing their code. For example, in the Java world there are some obvious things you need to watch for to avoid unnecessary performance hits – using StringBuilder instead of String while building strings for instance or avoiding Vector when you don’t need thread safety. The real problem occurs when developers are tempted into doing little tricks that they think will improve the performance of their code when they don’t know where the real performance bottlenecks are in the first place. This is premature optimization and and like many things that are premature¹ it can cause embarrassment and quite a few problems.

The use of the keyword final in Java is a perfect example. You can use it, as it was intended, to explicitly seal the implementation of a class so that it cannot be sub-classed, or a method so that it cannot be overridden by a sub-class. You could also choose to use it to improve performance of method calls by removing them from the vtable. Think about what you are doing first though. Nothing you mark as final can be subclassed or overloaded. If you believe that code should be self-documenting then you are making a bold statement about its design. Regardless, you’re restricting the behaviour of those classes when other developers go to use them². Is that what you want? Now think about the performance gain you’ve achieved. If you’re doing this before you’ve profiled the code to discover the real bottlenecks³ it’s the coding equivalent of ordering four Big Macs, two large fries, an apple pie and a Diet Coke.

The question about whether or not to declare a variable inside or outside a loop can be sort of couched in the same terms. There are going to be times where if you are creating a new object instance it might be more efficient to do that outside a loop rather than inside but that is down to the cost of invoking the object’s constructor. If you’re just talking about declaring a variable which will have an object reference assigned to it then you’re asking the wrong questions about your code. The rule should always be to keep your code clean and simple and in this case a good general rule of thumb is to keep the usage scope of a variable as small as possible.

Instead of doing this

private void someMethod() {
    SomeObject blah;
    for (int i = 0; i < 10; ++i) {
        blah = getBlah(i);
    }
}

you’re almost certainly much better off doing this

private void someMethod() {
    for (int i = 0; i < 10; ++i) {
        SomeObject blah = getBlah(i);
    }
}

For starters there’s no chance that the object will get re-used out of context (accidentally or otherwise) thereby reducing the potential for any bugs. Secondly it makes refactoring much easier. If you decide later on to extract the contents of the loop as a method everything that is local to the scope of the loop should come out cleanly. The bottom line is that the code is cleaner and easier to maintain. That is usually half the battle when it comes to having performant code but notice that the two reasons I give for doing it this way, and there are others, aren’t explicitly about performance.

Feel free to get into arguments about what kind of bytecode is generated when you declare a variable inside or outside a loop after you have run a profiler to find where the real bottlenecks are and have eliminated them⁴. I can practically guarantee you that you won’t have to resort to any tricks to improve performance. Chances are the problems will be with some part of the implementation. You may be using the wrong collection types, using the wrong search algorithm, not pooling resources correctly etc. I would be really surprised if attempting to influence how quickly a method was being called or how long it was taking to declare a variable in a loop resulted in a significant performance improvement in your code.

The first question any developer should ask themselves when writing new code, after the obvious one of what should this code actually do, is how clean and simple is the design? Inevitably a clean and simple design will be more efficient than a cluttered, trick-laden one. Keep it simple, make it work and then make it fast. As with most things in this business, the 80/20 rule applies and you’ll probably find that 80% of the time taken will be spent in 20% of the code. Find that 20% and improve its performance and you’ll see real and meaningful gains in the overall performance of your code but concentrate first on writing clean, clear and simple code.

Writing “clean and simple” code can be a subjective exercise but there are things you can do to help the process. Over the next few weeks I’ll be posting a series of articles on how test-driven development and the new kid on the block, behaviour-driven development, can help you achieve this goal.

I will now put the soapbox away.

– Fintan

I went to my first Ruby Tuesday meeting of the Ruby Ireland user group last night at La Taverna di Bacco in the grandly named Italian Quarter¹ just off Ormonde Quay here in Dublin. There was a pretty sizeable turnout for this relatively new and small but growing group. We did manage to stay on-topic for a while before the excellent wine and friendly atmosphere took hold.

I’m very much a “Ruby Newbie” as were a couple of the other attendees. I’ve come at it, like most people I suspect, through Rails which I’ve been looking at using for a pet-project I’m working on in my spare time. It was interesting to hear about some of the real commercial work that’s being done with Rails and Ruby in particular. For example, Fegal Byrne from Adnet uses Ruby for pretty much all of his scripting. Given that in general people tend to talk about Rails and Ruby in the same breath as if they were the same thing this was an interesting different perspective.

This should hopefully turn into a regular “Ruby Tuesday” on the first Tuesday of every month. Next month we’re hoping to have an overview of RSpec, a BDD framework for Ruby, from Ana Nelson² and something on REST using Ruby from Olivier Ansaldi. Looking forward to both with interest³.

– Fintan