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);
	}

}

                          

Typical Eclipse template for Google Collections

${:importStatic(com.google.common.collect.Lists.newArrayList)}newArrayList();
${cursor}
${:importStatic(com.google.common.collect.Sets.newHashSet)}newHashSet();
${cursor}

To use them, just open Eclipse Preferences: Java Editor: Templates.  Add new templates, and give them a name similar to the method.  I.e newArrayList.  Then your code completion hot key will run the template completing the text your typing in.  i.e you type newArrayList [code complete key] and it adds the static, and the rest of the method, placing your cursor at the end of the line.  Neat!

Note: See the comment from Yuri below, the above templates are no longer required for static imports. Its possible to configure the Content Assist to bring in a whole type, or member using Prefs:Java:Editor:Content Assist:Favorites. This is better as it scans all possible available methods in the type.

The code you end up with is tidy too:

List myList = newArrayList();

There is another thing I can never remember the syntax for!   The markup to add the syntax highlight for this blog. Available as a gist: http://gist.github.com/234709

                          

Its no revelation that Eclipse, Netbeans and others can generate code. Its particularly useful if getters, setters or constructors are required. Implementing an interface is very simple indeed as these IDE will stub out the interface methods. More complex methods though require some thought. Generation of the equals method is such a case.

How to write a good equals method is well documented by Joshua Bloch in Effective Java, Chapter 3 by Joshua Bloch.

Eclipse V Netbeans who generates the best code?

Before we get deeper into the code here are two efforts at generating the equals method for this class:

public class SimpleBean  {
    private final BigDecimal bigDecimal;
    public SimpleBean(BigDecimal bigDecimal) {
        this.bigDecimal = bigDecimal;
    }
}

The results for even such a simple class are interesting.

Netbeans

      @Override
      public boolean equals(Object obj) {
          if (obj == null) {
              return false;
          }
          if (getClass() != obj.getClass()) {
              return false;
          }
          final SimpleBean other = (SimpleBean) obj;
          if (this.bigDecimal != other.bigDecimal &&
                (this.bigDecimal == null ||
                !this.bigDecimal.equals(other.bigDecimal))) {
              return false;
          }
          return true;
     }

The Netbeans attempt is reasonable at first sight. Even with the above there are a few observations and a bug which I will come to later on. Can you spot it?

• The getClass system for checking that our object can be tested for equality is a little inflexible. For classes that implement a common interface its nice to be able to compare across implementations. This is often done using the if (!(obj instanceof MyType)) check. GetClass is optimal, but it would be good to have an option in the generation.
• The style of the value check is a little compressed for some tastes.

Eclipse

  @Override
  public boolean equals(Object obj) {
      if (this == obj)
	  return true;
      if (obj == null)
	  return false;
      if (getClass() != obj.getClass())
          return false;
      SimpleBean other = (SimpleBean) obj;
      if (bigDecimal == null) {
        if (other.bigDecimal != null)
          return false;
       } else if (!bigDecimal.equals(other.bigDecimal))
          return false;
       return true;
}

Eclipse generates very similar code. The bug is still there though, can you see it yet?

• Eclipse has extra options. You can switch out that getClass for the more flexible instanceof check.
• The style above is better and can be improved with the introduction of blocks on all if statements.
• Eclipse does more optimization assuming that more often than not an object is passed in.

Neither are good! The generated equals bug exposed!

It should be clear when I write a test that will fail for either of the above implementations.

@Test
    public void testObjectInconsistantWithEquals_Equals() {
        SimpleBean testSimpleBean = new SimpleBean(new BigDecimal("0"));
        SimpleBean expectedEqualSimpleBean = new SimpleBean(new BigDecimal("0.0"));
        assertTrue("Equality Test Fail", testSimpleBean.equals(expectedEqualSimpleBean));
    }
}

The above test fails because BigDecimal has an equals implementation that will return false when it checks 100 against 100.00. Its implementation of the compare method is declared as being inconsistent with equals. This in itself is interesting but for this example it means we can modify the generated code to provide a fix using this.bigDecimal.compareTo(other.bigDecimal) != 0 instead of relying on the generated use of equals.

Recommendations

In light of the above I would suggest the following points.

• Apart from primitive and well known objects generated equals methods can be very bad indeed.
• Always write a test for equals, do not rely on an IDE.
• If you change your object, remember to re-visit the equals method.