Archive for the ‘ Software ’ Category

Test Driven Development is not about testing

Dan writes:

bq. “Writing the test before you write the code focuses the mind – and the development process – on delivering only what is absolutely necessary. In the large, this means that the system you develop does exactly what it needs to do and no more. This in turn means that it is easy to modify to make it do more things in the future as they are driven out by more tests. ”

Read the rest here.

Breaking my silence

aslak_hellesoy: i was stoned when you put cheese in my source code

Toywatch: Whiteboard Photo

Mike Brown pointed me to Whiteboard Photo – a simple little tool for converting crappy photos of whiteboards into something usable. It even distorts the image to compensate for the perspective the photo was taken at.

!http://www.websterboards.com/media/products/BeforeAfter.jpg!

A mere $249 – good value for money.

OpenSymphony.com gets a facelift

OpenSymphony.com is looking nicer these days.

Discuss your maintainability patterns

If you’re anywhere near London on Tuesday 29th July, come along to the eXtreme Tuesday Club (XTC) and we can talk about the coding and design practices that make for maintainable code in the long term.

This is how we’ll do it. Prepare in advance.

Meanwhile, I’ve seen some excellent feedback on what makes for good maintainable code. There is a central overlap of core techniques that developers who have to maintain code in the long term have grown to adopted. And yet, even knowing these things work, they often slip our minds.

Design by contract: testing implementations of interfaces

Here’s a nice way of associating contracts with interfaces and testing the implementations conform.

A sample interface:

interface CheeseMaker {
int getCheeseCount();
void addCheese(Cheese cheese);
}

With the contracts:

* there should be zero cheeses on creation.
* adding a cheese should increment the count.
* unless the cheese is a duplicate.
* when adding a cheese, the cheese cannot be null.

You can create an abstract unit test for this interface that tests these contracts. The only thing it doesn’t do is provide an implementation – instead it has an abstract factory method.

public abstract class CheeseMakerTest extends TestCase {

// abstract factory method
protected abstract CheeseMaker createCheeseMaker();

public void testZeroCheesesOnCreation() {
CheeseMaker cheeseMaker = createCheeseMaker();
assertEquals(0, cheeseMaker.getCheeseCount());
}

public void testAddingACheeseIncrementsCount() {
CheeseMaker cheeseMaker = createCheeseMaker();
cheeseMaker.addCheese(new Cheese("Cheddar"));
cheeseMaker.addCheese(new Cheese("Wensleydale"));
assertEquals(2, cheeseMaker.getCheeseCount());
}

public void testDuplicateCheesesDoNotIncrementCount() {
CheeseMaker cheeseMaker = createCheeseMaker();
cheeseMaker.addCheese(new Cheese("Cheddar"));
cheeseMaker.addCheese(new Cheese("Cheddar"));
assertEquals(1, cheeseMaker.getCheeseCount());
}

public void testNullCheeseCausesIllegalArgumentException() {
CheeseMaker cheeseMaker = createCheeseMaker();
try {
cheeseMaker.addCheese(null);
fail("expected exception");
} catch (IllegalArgumentException e) {} // good
}

}

Now, every time you create an implementation of CheeseMaker, the test should extend CheeseMakerTest and you inherit the contract tests for free.

For example:

public class BigCheeseMaker implements CheeseMaker {
// ... ommited for sanity
}

public class BigCheeseMakerTest extends CheeseMakerTest {

// factory method implementation
protected CheeseMaker createCheeseMaker() {
return new BigCheeseMaker();
}

// ... any additional tests go here

}

It’s important to note that this tests the contract but does not enforce them. It’s very flexible and there are very few contracts (if any at all) that couldn’t be expressed in a unit-test.

This helps defensive development with the added safety of unit-tests.

As a bonus, you can use TestDox to generate documentation for interfaces (much more useful than implementations), like so:

h4. CheeseMaker

* Zero cheeses on creation.
* Adding a cheese increments count.
* Duplicate cheeses do not increment count.
* Null cheese causes illegal argument exception.

Maintainability patterns

I love tech. Look at all the fun stuff that’s happening in this development wonderland at the moment.

We have libraries to do everything under the sun. Persistence, web-apps, security, code generation, presentation, remoting, messaging, concurrency, XML processing, testing, containers, you name it. In Java-land, opensource seems to be dominating the market and we’re even starting to see books dedicated to the subject (end of shameless plug).

It’s easy to get seduced by the sparkle of how these tools can make magic happen quickly. With these tools, a system can be delivered in record time. Win!

But delivery is really just a short term win. After delivery comes maintenance and this is where most development teams get stung in the long term. It becomes harder and harder to add or refine features as time goes on. Chris Matts pointed out that over the life of a project, the cost spent on development is insignificant compared to the cost of maintenance.

It’s impossible for a sexy library alone to make your code maintainable. Using JUnit or an AOP library will not solve the problems. It’s the *techniques* that complement these that make applications more maintainable. The tools are just the icing on the cake and you really don’t have to use them.

The techniques are unfortunately less seductive than the tools, yet far more important. I often find myself answerless when faced with explaining the benefits of separating the interface from the implementation, using mock objects, inversion of control, aspect oriented programming or avoiding statics.

In most cases, I found there is no benefit of using a technique in isolation. Instead, they benefit each other. It’s the relationship between the techniques that are important and they all support one thing – maintainability. The relationships are patterns.

So, I have a theme for upcoming posts on the blog: *maintainability patterns*. What techniques we can employ to make code more maintainable and how they relate to other techniques.