It definitely needs editing and trimming and I can already see ways in which inconsistencies have crept in. I’ve also managed to introduce a little sub-plot which right now seems to have absolutely no purpose and I’ve completely failed to establish certain things about my central character which are important.

I can fix all that next month though. For now it’s about getting the 50,000 words done even if they do edit down to about 20,000!

On the practical side I’ve been doing all the writing on my MacBook using Jer’s Novel Writer. It’s a pretty good tool but it’s had a few revisions recently which broke and then fixed the word count. The annoying part was that I wasn’t able to get onto the message board to report the bug. I had to register but I’m still waiting for my confirmation email so I can log in. Boo!

The daily word count which I enthusiastically tweet about on Twitter is based on the figure reported by Jer’s Novel Writer. My daily totals were based on the word count that NeoOffice reports³. Today I started using the NaNoWriMo word count utility and discovered that it doesn’t agree with what NeoOffice says. I’m going to go with what NaNoWriMo say – they’re the ones deciding whether I’ve passed or not.

I’m something of a notorious procrastinator so one way in which I warm up before starting a session is to do some deliberate procrastination. I check my mail, read my RSS feeds and look for any missed tweets on Twitter. I spend about 20 or 30 minutes just generally browsing the web and then get started. I’ve also done most of my writing in my dining room rather that at the desk in my study. I reckon there are too many distractions in there⁴ and if I sit at the end of the dining table I can actually put my feet up on the other chairs. I’m almost in a reclining position as I write.

I’m looking good in good shape to hit the 50,000 word target at the moment but part of me secretly hopes that 50,000 words won’t be enough to actually finish this thing and I’ll have to keep going through December too!

– Fintan

A mate of mine in school had the WM-10 and I loved how small it was. It was the same size as a cassette case but it expanded a little wider when you wanted to actually put a tape into it. The WM-102, which came out a couple of years later, went a bit further. It took the battery out of the body altogether and stuck it in a little box on the bottom. You could either use the slim rechargeable one or a standard AA battery. With the rechargable one the whole package was super small and genuinely the same size as a cassette case.

This picture here² is what you got in the pack. I bought mine in 1987, the year they came out, with the winnings from a lottery scratch card. I can’t remember how much it cost but I seem to remember having to put some money towards the £100³ that I won. Finding this site really brought back some memories of old-school⁴ technology envy.

It also made me remember just how dominant Sony were in the portable music player space at the time. Sure there were other manufacturers like Aiwa and Akai but Sony were top dog. It always amazes me how they completely blew the portable music space when MP3 came along. They seemed to be so busy fighting the change in the way people were listening to music that they didn’t produce a digital music player until very late in the game. Even then they refused to support MP3, presumably because they were afraid of piracy issues, and instead came up with their own “standard” ATRAC.

Friends of mine came back from New York recently where they each bought themselves one of these beauties which I think are fantastic. Just as soon as I can find some spare cash to spend on one of them I will⁵. Still, I have fond memories of my trendy little Walkman from the 1980s for a lot of different reasons and I’m sure Sony do too.

– Fintan

It’s a pity because I really like the service, especially the way I could almost treat it as an aggregator for my del.icio.us links and snippets of my blog entries. I didn’t like the way it pulled in all my tweets from Twitter² so I’d created a simple but nifty pipe on Yahoo! Pipes! to filter out replies to other people and remove the leading “fintanp:” and imported that as a regular RSS feed. I hadn’t started pulling in photos from Flickr yet³ but did post the occasional one taken with my phone. I hope they fix it soon or I’ll have to move to a competitor like these guys.

The last couple of days have made me realise just how reliant I am on hosted services like wordpress.com for this blog. I’m going to have to organise my own soon.

– Fintan

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

The reason I’ll be going dark is that I’ve decided to take part in this years NaNoWriMo challenge. I’m probably mad because I’ve just looked at my calendar for the month of November and I reckon that between a trip to France in the middle of the month and a visit from my U.S.-based mum (plus a bunch of other stuff) I really only have two and a half weeks to write my 50,000 word novel. This should be fun.

But sod it I’ve been planning this for a year so I’m going to do it. I’ll keep you posted on how I’m getting on.

– Fintan

What is the accepted definition of Web 2.0 anyway²? In a very real sense it’s a term that was coined by Tim O’Reilly to sell convention space. As he said in this article recently:

Web 2.0 started out as the name of a conference! And that name had a very specific purpose: to signify that the web was roaring back after the dot com bust! The 2.0 bit wasn’t about the technology, but about the resurgence of interest in the web.

And yet people insist on talking about being “Web 2.0″ and having “Web 2.0″ elements whether it’s some kind of social networking³ thingy, using a bit of AJAX for a more interactive browser experience or just having a fancy reflective logo and a nice colour scheme. I’m reminded of an old boss of mine who, back in the very early ‘90s, wanted to know if our product was “client-server”. He couldn’t define what he meant by that but it was obvious that he wanted to go out to customers and impress them with the fact that we supported the latest industry buzzwords⁴. The same is true with Web 2.0. People have heard of it so they feel that have be doing it… whatever “it” is.

The worst part about all of this is that the “2.0″ part of Web 2.0 is now being applied to other things like publishing, charity and something called Lunch 2.0 which I guess is some kind of networking thing⁵. Hell even movies are getting in on the act with Die Hard 4.0⁶ aping the theme. Does that mean there’s going to be a Die Hard 4.1? What’s that? The directors cut?⁷

Yesterday I saw one that really took the biscuit:  Firestorm 2.0

Now I know that this is referring to a collection of “social networking” sites where “user generated content” is being used to track the fires currently devastating parts of California but really! Stop 2.0! Enough Already 2.0!

There’s a lot of really cool stuff going on right now, some of which has changed the way we’ll use the web forever but the more I see this kind of thing the more I definitely think we’re in a bubble. It may be different to the dot-com one but it’s a bubble nonetheless and that is bringing the marketing bandwagon jumpers out of the woodwork. It gets worse when some people are now trying to define Web 3.0, sometimes in terms of their own product much to people’s dismay.

We may very well need a label to describe the period were going through in terms of the changes in how the Internet in general and the web in particular are being used. The name “Web 2.0″ may fill that role but can we stop using a non-specific inexact term in a very specific way?

– Fintan 1.0

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 scamall

Some rights reserved.

Damien Mulley has a series of posts about how to rig the Irish election and it all sounds like a fierce hard amount of work to me. I have a much simpler idea about how you might influence the outcome of a general election in Ireland¹.

1. Make sure your political party has a well organised grass-roots movement like, say, this one does.

2. Make excuses and some lame attempts to embarrass the public into accepting e-Voting machines, solving a problem that doesn’t exist². You could try these ones. I think we already have some in stock.

3. Call the election for a weekday rather than a weekend for the convenience of voters.³

4. Use the aforementioned grass-roots movement, and perhaps some friendly mini-bus owners, to bus voters to the polling places early to form long lines out the door.

5. Encourage these early voters, especially the loyal elderly ones, to become “confused” and take their time in figuring out who to vote for. So many candidates…. What button do I press again? This will delay voters for other parties who may, in their frustration, just go home without voting.

6. Announce the results at 3am in a PowerPoint presentation and quietly mention the fact that although there’s no paper trail the result can be trusted because computers never lose votes. The turnout may be low (see previous point) but at least the majority voted for your party.

As a backup plan try to figure out some way of hacking the secure e-Voting machines. You could always use this document as a starting point.

Okay so it’s hardly a realistic scenario but like Damien I’m being satirical…

– 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