I have found that quite a few programmers struggle to work in a completely test driven fashion. I myself whilst writing tests for many years, took a long time to move over to writing the test first. I think one of my problems was that I always wanted to do my thinking in the implementation class. Recently I have found a great way to leverage the Eclipse IDE’s code complete functions so that its more natural to work from the test class.

The idea is to save effort and time by getting Eclipse to create the implementation side. I have long been used to changing the code, and then using code complete to refactor. For instance you can change a class name or package name, and use CTRL-1 to get a list of options on the code that will not compile. Then use an option to move or rename the class performing the re-factor.

This turns out to be a very powerful technique for driving development from the test.

Try out this simple example I think it makes it more natural to TDD, but I would be interested in your comments.

Start by creating a test class the usual way, and put your test method in it.

@Test
public void testDrivingFromTheIde () {

}

Next I need a new service type, and an implementation. So in the test just type what you think you will need.

public void testDrivingFromTheIde () {

long factor;
NumberCruncher numberCruncher = new ComplexNumberCruncher(factor);

}

The new code does not compile as its missing the classes, so driving from the test, press your code complete key, CTRL+1 in eclipse. Up pops a list of operations like this:

Code complete options showing create class and interface

Select create new interface, remember to change the location from test to main or the class will be created in the wrong folder. Note if your using netbeans you don’t get as rich an editing experience, it only gives you the option to create a class, and in the wrong folder, so you have to move it and change it to an interface. This undoes what I am trying to achieve, which is to spend as much time in the test class as possible.

Creating an interface

Back in the ide you will be looking at your new class, hit ALT-left to return to the test class. Note its still not compiling so again, as an alternative this time just hover over the problem and select create new constructor from the options.

Finally back in the class you can fix the remaining problem and initialize the variable. Now add the call under test to the code, and again use code complete to add the method to the interface. Navigate to the ComplexNumberCruncher class and a quick CTRL+1 will give you the option to add unimplemented methods from the interface. Save and move back to the test again. Add your missing assertions and run the test, it should fail.

At this point you have written a few lines of test, and managed to generate the implementation skeleton.  All that remains is to finally implement the compute method.  This bit eclipse will not do for you.    So switch back to your compute method, and implement it.  In a more complex implementation you may find yourself adding more assertions, and implementation incrementally.  This is pretty normal.  For me leveraging eclipse makes it much easier to write the code in a true TDD way. Less typing and I am sure it takes less time.

public void testDrivingFromTheIde () {

		long factor = 5;
		NumberCruncher numberCruncher = new ComplexNumberCruncher(factor);

		long value = 10;
		long result = numberCruncher.compute(value);

		assertNotNull(result);
		assertEquals("5 x 10 = 50",(factor*value),result);
}

public interface NumberCruncher {

		long compute(long i);
}

public class ComplexNumberCruncher implements NumberCruncher {

	private final long factor;

	public ComplexNumberCruncher(long factor) {
		this.factor = factor;
	}

	@Override
	public long compute(long value) {

		return (this.factor * value);
	}

}