Cuban Car: Martin Harris

Well perhaps not Nirvana then, but at least having a suitable level of test coverage. 

I wanted to write an article around the uptake of test driven development. Scrum and agile are hard to do well. If you break these down, you often find that the components are pretty challenging too. TDD is difficult but it has gained widespread recognition at the intellectual level.  On the ground though the practice can be patchy. Why?

Before writing this article I had a look around to see what else had been written.  This article on Geiger’s Counterpoint sums up my thoughts exactly.  Its such a good article that I hardly have anything left to say.  In fact neatly I can just provide some bullet points!

Improving the uptake of Test Driven Development

Programmers need help to adopt test driven practice.  So how can you go about that?

• Lead from the front: If your senior developers are not checking in fully tested code it will destroy the practice.  Its highly demoralising to be producing well tested code only to have a senior ruin it by checking in code with partial coverage.  I can not stress hard enough that the practice must come from the top.
• Pair code and mentor the practice: I have yet to meet a developer that took to TDD right from the off.  Most people struggle to produce good code, and TDD is far from intuitive.  The best way to improve is to see good code and work with people that write good code.  So mentor and pair code to disseminate the practice.
• Use coverage reporting: Use tools like clover, cobertura and emma to provide reports so that you can see what lines of code are covered by tests.  Make this reporting part of your build.  Encourage developers to use coverage reports to check the quality of their testing practice.  Understand though that coverage is not everything you need to concern yourself with, sensible assertions are important too.
• Encourage discussion: Next time you find something un-tested in your codebase, create a discussion about it.  Sometimes there are reasons, its badly written making it difficult to test.  Perhaps its an  integration point.  Through discussion you will encourage the team to find a solution and write some tests.
• Set a bar: Find a way to set a bar.  i.e find the current coverage levels and don’t allow the numbers to fall.  I worked on a project where a custom build component was added.  It parsed the clover reports, found the current coverage level and broke the build if it fell after checkin.

Summary

Most project suffer lower levels of test coverage than ideal.  Encourage test driven development and find ways to teach how it can be done.  Create dialog and get the teams to self organise around the goal of improving test quality and coverage.  Use tools and processes to support the team.

                          

for(String name: names.keySet()) {
    mymap.put(mymap.get(name),name);
}

Its inefficient because you have to fetch the keys and perform a lookup in the map with the key.

Instead using the EntrySet you can get all the keys and values in one hit. This saves having to perform the map lookup.

for (Entry<String, String> entry : entrySet) {
    mymap.put(entry.getValue(),entry.getKey());
}

                          

Be careful to check that your objects are consistent with equals though.  I have mentioned this before.

In the following method I am using the Objects.equal with a BigDecimal class.  It does not work because BigDecimal equals treats 0 and 0.0 as not equal, which is probably not what you need.

public boolean equals(Object obj) {
    if (obj == null) {
      return false;
    }
    if (getClass() != obj.getClass()) {
      return false;
    }

    final TestEquals other = (TestEquals) obj;

    return Objects.equal(this.bigDecimal, other);
}

The common solution is to use the compareTo method instead like so.

  final TestEquals other = (TestEquals) obj;
  if (this.bigDecimal != other.bigDecimal &&
      (this.bigDecimal == null
      || this.bigDecimal.compareTo(other.bigDecimal) != 0)) {
    return false;
  }
  return true;

I will be using this technique, especially where the object has many attributes but I will be testing the equals method.

                          

Look at these two setters. Setter methods like the first example are very common. Take a look at the second its so much better. With the second the responsibility to convert is neatly delegated to another class instead of forcing the user of the api to work it out. In addition the programmer can supply hours, minutes or any other that TimeUnit supports.

public void setDuration(long durationInMs) {
    this.duration = durationInMs;
}

public void setDuration(long duration, TimeUnit timeUnit) {
    this.duration = timeUnit.toMillis(duration);
}

TimeUnit was brought to you by: java.util.concurrent.TimeUnit! Its handy, so use it!

                          

Take a look at this interface.  If I find this populate method, I am likely to have to open implementations.  I don’t know if it populates one map from the other or both maps.

import java.util.Map;

public interface NastyPopulator {

void populate(Map<String, String> driver, Map<String, String> driverHolder);

}

The problem is the semantics of map are that you can read from maps or you can write to them.  I think this is a slightly better approach below.

I have used ImmutableMap.Builder.  The semantics of this are that it is used to build things.  I will call build() on the object later to get a map.  Next its an ImmutableMap.  So not only am I declaring that the two parameters are likely to be used to build something, that thing will ultimately be Immutable so in effect the signature declares that I am not expected to make modifications later.  Finally the method name is unambiguous buildMaps, which pretty much says what its going to do.

import com.google.common.collect.ImmutableMap;

public interface LessNastyPopulator {

void buildMaps(ImmutableMap.Builder<String, String>  driver, ImmutableMap.Builder<String, String> driverHolder);

}

Feels like a stronger declaration to me. If ImmutableMap is awkward you could define your own static builder and pass that in, at least your still declaring up front, that this method is builds the two maps. If the method is reading from one map and building others, how about passing an iterator and a builder?

                          

Have a read over the class, and then move on to read the steps to re-factor to better patterns. I have several designs here that focus on the setup stage of a test. As your tests get more complex you will find the patterns here support ever increasing complexity. In an Agile project you might move from one system to the next as the requirements ramp up. Then once you see where I am heading, I lay down a challenge.

Test anti-patterns project, contributors wanted!

If you have a Test Anti-Pattern that you would like to showcase. Check out my code from gitHub, add the new example and examples of how to re-factor the code. Blog it to your own blog with a reference to this page, or drop a comment. If we get enough I will setup a page with an index to all the blogs.

The code can be forked out with git from gitHub http://github.com/mhgit/TerribleJavaTestingMadeGood. It should be an easy start. Its a full maven project with a small dependency set and maven site reports already built in for test coverage. Its fully open source with the Apache 2.0 license. Once you have your new example, tell me about it by adding a comment to this page, and following the git forking instructions for making a git pull available.

I hope I never see another badly written test like this:

…but unfortunately I probably will…

package org.testpatterns.dupcodeexample.lineutil.unit;

  import org.testpatterns.dupcodeexample.lineutil.SimplePage;
  import java.util.HashMap;
  import java.util.Map;
  import java.util.Set;
  import org.junit.Test;
  import static org.junit.Assert.*;

  /**
  * Terrible Test SimplePage Function.
  *
  * @author martinh
  */
  public class TerribleSimplePageTest {

    @Test
    public void testPageAssembley() {

        String item = "-23456789-";

        Map<Integer, String> expectedLines = new HashMap<Integer, String>();

        expectedLines.put(1, item + item + item + item + item);
        expectedLines.put(2, item + item + item + item + item);
        expectedLines.put(3, item + item + item + item + item);
        expectedLines.put(4, item + item + item + item + item);

        SimplePage page = SimplePage.newInstance(item, 20);
        Map<Integer, String> actualMap = page.getMap();

        assertEquals(expectedLines, actualMap);

    }

    @Test
    public void testPageKeySet() {

        String item = "-23456789-";

        Map<Integer, String> expectedLines = new HashMap<Integer, String>();

        expectedLines.put(1, item + item + item + item + item);
        expectedLines.put(2, item + item + item + item + item);
        expectedLines.put(3, item + item + item + item + item);
        expectedLines.put(4, item + item + item + item + item);

        SimplePage page = SimplePage.newInstance(item, 20);
        Set<Integer> actualKeySet = page.getKeySet();

        assertEquals(expectedLines.keySet(), actualKeySet);

    }

    @Test
    public void testAddLines() {

        String item = "-23456789-";

        SimplePage page = SimplePage.newInstance(item, 20);

        Map<Integer, String> additionalLines = new HashMap<Integer, String>();

        additionalLines.put(1, item + item + item + item + item);
        additionalLines.put(2, item + item + item + item + item);
        additionalLines.put(3, item + item + item + item + item);
        additionalLines.put(4, item + item + item + item + item);

        page.appendLines(item, 20);

        Map<Integer, String> actualMap = page.getMap();

        Map<Integer, String> expectedLines = new HashMap<Integer, String>();

        expectedLines.put(1, item + item + item + item + item);
        expectedLines.put(2, item + item + item + item + item);
        expectedLines.put(3, item + item + item + item + item);
        expectedLines.put(4, item + item + item + item + item);
        expectedLines.put(5, item + item + item + item + item);
        expectedLines.put(6, item + item + item + item + item);
        expectedLines.put(7, item + item + item + item + item);
        expectedLines.put(8, item + item + item + item + item);
        assertEquals(expectedLines, actualMap);

    }
}

Fixture as a normal method: ImprovedSimplePageTest

I am not going to post up code for all the classes. Check it out from gitHub for that. So I just highlight the main steps and show the final full class.

The basis of the first pattern is simple. Most small tests like this just need one method for setup, this eliminates all the cut and paste. This might be run from an @Before, or @BeforeClass annotation, as part of the constructor or perhaps just from the test itself. These techniques will have to be applied depending on what you need to achieve. For instance if your setup is inserting into a database, you have to make sure your data does not violate db constraints. So the annotations might not help, plus you have the added complexity of getting hold of your database. A good pattern is to use an in memory db, but some of the annotations will cause the setup to get run before each test. So in a nutshell attempt to have one setup, and its not that important which system you use to run it, that will depend on what your doing.

Refactoring steps:

• Rename methods.

Have a good strategy for your test names if they are good enough you will not need to comment the methods. The pattern I use here is: [What is being tested]_[What is expected]. If you can’t fit it all into the name, the test is probably too big and needs breaking down. A test should be concise.

• Remove duplication.
There were two steps to this:
1. I Added this method: createLineExpectations to create expectations.

This allowed me to remove all the duplicated test setup that had been cut and pasted all through the class. I wrote this bad test, using TDD to come up with the supporting implementation, so even as I wrote it the test went through several iterations. During that process I left a chunk of unused map behind. Which just goes to prove that if your test is messy, its difficult to spot problems.
An unused chunk of code that hid in the duplications

  Map<Integer, String> additionalLines = new HashMap<Integer, String>();

  additionalLines.put(1, item + item + item + item + item);
  additionalLines.put(2, item + item + item + item + item);
  additionalLines.put(3, item + item + item + item + item);
  additionalLines.put(4, item + item + item + item + item);

2. Added constants and moved all the hard coded value out.

Collecting setup into an inner fixture class: LocalFixtureBasedPageTest

Its not long before the technique starts to breakdown. As you add more supporting methods it gets harder to see what is test, and what is setup. So the next stage is to move the setup into an inner class. This way, most ide’s will allow you to collapse the fixture hiding it away. When I read a test, I am mostly interested in the expectations, not the setup. Note that the constants have been moved into the fixture. So the fixture becomes an inner class that supplies everything to do with setup for the test.

    private class DataFixture {

        private final String ITEM = "-23456789-";
        private final int LINES_8 = 8;
        private final int LINES_4 = 4;

        Map<Integer, String> createLineExpectations(String item,
                int numLinesToCreate) {
            Map<Integer, String> expectedLines = Maps.newHashMap();

            StringBuilder sb = new StringBuilder();
            sb.append(item).append(item).append(item).append(item).append(item);
            String line = sb.toString();
            for (int i = 0; i < numLinesToCreate; i++) {
                    expectedLines.put(i + 1, line);
            }

            return expectedLines;
        }
    }

Fixture as a spring injected component: SpringWiredSimplePageTest

When a test gets more complex you sometimes end up with masses of complexity building up in inner classes. I sometimes use inner classes to build complex data requirements using the setter method chaining pattern for instance. Each inner class becoming a container for parameterized setup. The next level of complexity is needing to share the setup over many test classes.

These are your options.

1. Create a static helper class

Not a bad solution, but I hate having to access the methods via the class name. Static classes often collect unrelated methods too. Also, its often not possible to work with the restriction of being static.

2. Abstractions and class hierarchy.

This is often posed as a solution when you need to share the setup over many classes. In this case its a terrible solution. The abstraction gets further complicated because your using the wrong OO mechanism. It also means your test has to extend a class, in some situations, you are already extending to get at the internals of the object under test.

3. Use method injection to supply a fixture component.

If you break the fixture out to a component its easier to manage the complexity of the fixture away from the test with composition. You can have many components each doing something specific for a set of tests. You could even inject more than one component. The design of the fixture can use other OO patterns to keep it neat. For instance I once built a set of fixtures to supply ready made folder and file structures. They all extended an abstract and implemented an interface. The @Qualifier annotation was used to inject the correct implementation into the test. On occasion a test used two of the component implementations.

Refactoring steps:

• Move the Fixture inner class to its own component class. If you get many of these its worth putting them in a separate project.
• Add the @Component annotation from the spring project.
• Change the type giving a more descriptive name.
• Make the methods in the fixture public.
• Better names for methods and types now that the fixture is not near the code that uses it.
• Java doc for important methods.
• Addition of getters for fields instead of direct access.
• Improved createLineExpectations(int numLinesToCreate) by removing the dataItem, the fixture knows this data so no need to supply via method.
• Convert to spring test. This means its possible to load in the spring configuration and autowire the test

The test class markup to convert it into a spring test, and provide amongst other things auto wiring:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = "classpath:springAppConfig.xml")
@TestExecutionListeners({DependencyInjectionTestExecutionListener.class})
public class SpringWiredSimplePageTest {

Autowire the fixture, and spring will inject it:

@Autowired
    private PageDataFixture dataFixture;

Your test setup is then just called like this:

Map<Integer, String> expectedLines = dataFixture.createPageExpectation(NUMBER_LINES_ON_PAGE_4, NUMBER_DATA_ITEMS_IN_LINE_5);

Conclusions

Once you have a test that gives 100% coverage, there is usually some more time that needs to be spent on cleaning the code. There are some easy patterns that can help, there is nothing in this article that is complex or difficult to understand so there is no excuse for leaving it messy. Bugs hide in messy code and I think you would agree, the final result is very easy to read:SpringWiredSimplePageTest

Thanks to…

All the people I have worked with over the years, who have shown me better ways to write and test code. You know who you are. Many thanks.

                          

But the devil is in the detail so here it is anyway.

I have this multi threaded application. One of the problems with integration testing it is, you can’t guarantee the order that messages will be written to a stream. So during the test I have to go to some trouble to split and order the lines written out. If I don’t do this the test fails sometimes. It depends on which thread writes first. The output though is correct, order is not important. Not exactly rocket science.

Here is the method I was using to massage the string.

 public List<String> getSortedLines(String expectedString) {

        String[] splitExpectedResultLines = expectedString.toString().split("\n");
        List<String> resultLines = new ArrayList<String>();
        for (String messageLine : resultLines) {
            resultLines.add(messageLine);
        }

        Collections.sort(resultLines);
        return resultLines;
    }

There is nothing particularly wrong with the method. It takes a string, splits it into lines, loads a List, sorts and returns it. Thus when its used in an assertion later the expected and actual lists are the same.

With google collections its just three lines! The HashMultiset is designed to be used in equals methods. Its equal even if the order of the elements in collections being compared is different. From the API documentation: An extension of Collection that may contain duplicate values like a List, yet has order-independent equality like a Set. One typical use for a multiset is to represent a histogram.

Its possible to use the HashMultiSet.create static factory method, passing in an Iterable. i.e a Collection. So from the original code, both the loop and the Collections.sort are no longer required.

   public HashMultiset<String> getOrderAgnosticCollection(String expectedString) {

        String[] splitExpectedResultLines = expectedString.toString().split("\n");
        Iterable<String> resultLines = Arrays.asList(splitExpectedResultLines);
        HashMultiset<String> orderAgnosticResultLines =
                                              HashMultiset.create(resultLines);

        return orderAgnosticResultLines;
    }

If there was something that performed the split, but returned an Iterable the method would be perfect!

                          

All good java programmers know the equals and hashcode methods are vitally important. I have seen some unpredictable behavior through bugs in these two methods.

If your about to click away to something more interesting fine, but first read my page with an example equals bug. See if you can spot the problem before I show the solution.

Writing a test for the equals method

Writing a test for equals is so easy its tedious. Which is perhaps why so much code gets written and not tested. First from the javadoc what are the specifications for a good equals and hashcode implementations?

Suns javadoc for the equals method

• It is reflexive: for any non-null reference value x, x.equals(x) should return true.
• It is symmetric: for any non-null reference values x and y, x.equals(y) should return true if and only if y.equals(x) returns true.
• It is transitive: for any non-null reference values x, y, and z, if x.equals(y) returns true and y.equals(z) returns true, then x.equals(z) should return true.
• It is consistent: for any non-null reference values x and y, multiple invocations of x.equals(y) consistently return true or consistently return false, provided no information used in equals comparisons on the objects is modified.
• For any non-null reference value x, x.equals(null) should return false.

Suns javadoc for the hashcode method

• Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified. This integer need not remain consistent from one execution of an application to another execution of the same application.
• If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result.
• It is not required that if two objects are unequal according to the equals(java.lang.Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results. However, the programmer should be aware that producing distinct integer results for unequal objects may improve the performance of hashtables.

Simple implementations for equals and hashcode

These two implementations were built using the generator in netbeans. Arguably some further optimisation could be done, especially if the class were made fully immutable. They are fine for the purpose of this blog.

public final class SimpleBean {
    private Integer goodInt = 0;

    public SimpleBean(final Integer goodInt) {
        this.goodInt = goodInt;
    }

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

    @Override
    public int hashCode() {
        int hash = 7;
        hash = 41 * hash + (this.goodInt != null ? this.goodInt.hashCode() : 0);
        return hash;
    }
}

Test class for SimpleBean just showing the equals and hashcode tests

import org.junit.Test;
import static org.junit.Assert.*;

public class TestSimpleBean {

    static final class Fixture {

        static SimpleBean x = new SimpleBean(new Integer(100));
        static SimpleBean y = new SimpleBean(new Integer(100));
        static SimpleBean z = new SimpleBean(new Integer(100));
        static SimpleBean notx = new SimpleBean(new Integer(1));
    }

    @Test
    /**
     * A class is equal to itself.
     */
    public void testEqual_ToSelf() {

        assertTrue("Class equal to itself.", Fixture.x.equals(Fixture.x));
    }

    /**
     * x.equals(WrongType) must return false;
     *
     */
    @Test
    public void testPassIncompatibleType_isFalse() {
        assertFalse("Passing incompatible object to equals should return false", Fixture.x.equals("string"));
    }

    /**
     * x.equals(null) must return false;
     *
     */
    @Test
    public void testNullReference_isFalse() {
        assertFalse("Passing null to equals should return false", Fixture.x.equals(null));
    }

    /**
     * 1. x, x.equals(x) must return true.
     * 2. x and y, x.equals(y) must return true if and only if y.equals(x) returns true.
     */
    @Test
    public void testEquals_isReflexive_isSymmetric() {

        assertTrue("Reflexive test fail x,y", Fixture.x.equals(Fixture.y));
        assertTrue("Symmetric test fail y", Fixture.y.equals(Fixture.x));

    }

    /**
     * 1. x.equals(y) returns true
     * 2. y.equals(z) returns true
     * 3. x.equals(z) must return true
     */
    @Test
    public void testEquals_isTransitive() {

        assertTrue("Transitive test fails x,y", Fixture.x.equals(Fixture.y));
        assertTrue("Transitive test fails y,z", Fixture.y.equals(Fixture.z));
        assertTrue("Transitive test fails x,z", Fixture.x.equals(Fixture.z));
    }

    /**
     * Repeated calls to equals consistently return true or false.
     */
    @Test
    public void testEquals_isConsistent() {

        assertTrue("Consistent test fail x,y", Fixture.x.equals(Fixture.y));
        assertTrue("Consistent test fail x,y", Fixture.x.equals(Fixture.y));
        assertTrue("Consistent test fail x,y", Fixture.x.equals(Fixture.y));
        assertFalse(Fixture.notx.equals(Fixture.x));
        assertFalse(Fixture.notx.equals(Fixture.x));
        assertFalse(Fixture.notx.equals(Fixture.x));

    }

    /**
     * Repeated calls to hashcode should consistently return the same integer.
     */
    @Test
    public void testHashcode_isConsistent() {

        int initial_hashcode = Fixture.x.hashCode();

        assertEquals("Consistent hashcode test fails", initial_hashcode, Fixture.x.hashCode());
        assertEquals("Consistent hashcode test fails", initial_hashcode, Fixture.x.hashCode());
    }

    /**
     * Objects that are equal using the equals method should return the same integer.
     */
    @Test
    public void testHashcode_twoEqualsObjects_produceSameNumber() {

        int xhashcode = Fixture.x.hashCode();
        int yhashcode = Fixture.y.hashCode();

        assertEquals("Equal object, return equal hashcode test fails", xhashcode, yhashcode);
    }

    /**
     * A more optimal implementation of hashcode ensures
     * that if the objects are unequal different integers are produced.
     *
     */
    @Test
    public void testHashcode_twoUnEqualObjects_produceDifferentNumber() {

        int xhashcode = Fixture.x.hashCode();
        int yhashcode = Fixture.notx.hashCode();

        assertTrue("Equal object, return unequal hashcode test fails", !(xhashcode == yhashcode));
    }
}

Conclusions

To me the benefit is clear. Its very easy to break these two methods. Converting one of the attribute types can easily break equals and possibly hashcode. Its essential to have a test in place to prevent the bug going unnoticed.

Note on nulls

In some cases extra tests may be required for null checking on both sides. For instance in the case where an object relies upon an inner class to provide it a key, and its possible for this key to be null.:

   /**
     * x.key = null, y.key = null, must return false.
     */
    @Test
    public void testKeysNull_NotEqual() {

        Thing noKeyAvailableA = new Thing();
        Thing noKeyAvailableB = new Thing ();
        assertFalse(noKeyAvailableA.equals(noKeyAvailableB));
    }

    /**
     * x.key= null, y.key != null, must return false.
     */
    @Test
    public void testKeyNearsideNullFarsideNotNull_NotEqual() {
        Fixture fixture = new Fixture();
        Thing noKeyAvailable = new Thing ();
        assertFalse(noKeyAvailable.equals(fixture.x));
    }

    /**
     * y.key = null, x.key != null, must return false.
     */
    @Test
    public void testKeyFarsideNotNullFarsideNull_NotEqual() {
        Fixture fixture = new Fixture();
        Thing noKeyAvailable = new Thing ();
        assertFalse(fixture.x.equals(noKeyAvailable));
    }

                          

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.