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

                          

1. 21:45 Open Eclipse.
2. 21:49 Updates downloaded and maven re-indexed.
3. 21:53 Start tutorial, lots of downloads from maven after project creation.
4. 21:55 Restart eclipse to enable the runtime weaving, STS does not return…restarted it from the prompt, deleted the project and started again as it looked incomplete.
5. 22:00 Bumbling through the tutorial.  This is very easy, love the CTRL^space completion.  I have done quite a bit of Linux work, and this shell is very easy to use.
6. 22:14 Running the tests using roo> perform test. This runs maven, which fails because it cant find the integration test class, RsvpIntegrationTest.  Investigation from the bash prompt reveals that all tests pass under maven, so its not an issue with the project roo has created.  More download and fiddling about.  The test runs from eclipse too, so I move on.
7. 22:38 Website up! Selenium tests all pass.  Investigation of the functionality shows that its working!  Done in 53 mins not bad I think!

Roo Up and Running!

Conclusion

Yea easy, a quick look over the project shows its very neat and tidy. Most of the time was spent in download and the false start. The configuration easy to follow and the generated code would be easy to use. So yes, might have a proper look at Roo at some point!

                          

I used Spring STS for a few months before starting at Lab49, and found it to be a good distribution over the standard Eclipse build. It has lots of extra productivity features for Spring based development some of which are not available by downloading Spring plugins and adding them to a normal distribution.
The things I like best are:

• The edit, navigation and search systems now support the spring annotations. So now you can navigate and search for beans declared via annotations.
• Ability to include new XML domains in the spring configuration from a popup list.
• The enhanced XML editing support now has inline error checking.
• This XML editor also supports completion and checking of class and bean names.
• Roo shell looks interesting too.

Roo and Roo Shell
The Roo system looks great. Its a system to generate and support a JEE system. The roo shell can be used to configure JEE components. You can have a basic website up in seconds. Like Groovy and Grails you get spring standards built in, and your not dependent on the Roo system once your finished.

I am going to take a proper look at it at some point.

                          

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.