Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Best practices for test-driven development

Simplify your application of TDD

By Michael Grove and Brooks Bollich, JavaWorld.com, 05/10/04

Page 3 of 5

An easy solution to this problem is to create a helper mock-object subclass that implements/extends the interface/class and provides an implementation for every method that simply throws a RuntimeException, e.g., throw new RuntimeException("Operation not supported"). A good IDE can easily create such a class for you. Use this class as the base class for all future mock objects of this type. The mock objects that derive from this base mock class will only need to override the methods of the parent class relevant for the particular test in which they are used. An additional benefit is that if you accidentally forget to override a method necessary for the test, your test will fail with a thrown RuntimeException. This immediately identifies which additional method your mock object needs to override.

Let's return to our example of a constructor that throws RuntimeExceptions if required constructor arguments are invalid. In such a case, we create a helper mock-object subclass that provides valid constructor arguments to the superclass. For example:

public class Group {
   private final String groupName;
   public Group(String groupName) {
      if (groupName == null) 
         throw new IllegalArgumentException("groupName cannot be null");
      }
      this.groupName = groupName;
   }
   // Group methods...
}
public class MockGroup extends Group {
   public MockGroup() 
      super("");
   }
}

Now to create mock subclasses for Group, you can extend MockGroup and not worry about exception conditions in Group's constructor.

Best Practice 3: Use immutable objects

An immutable object is an object that cannot be modified after creation. When at all possible, you should define classes to be immutable. This simplifies your class and its testing. When classes are mutable, the number of test cases tends to be much higher than in immutable classes. Mutable objects can have different internal states throughout their lifetime, all of which need to be tested explicitly. For example, when testing a mutable class, you often need to test the case where a get() accessor method is called before the associated set() method has been called. These test cases do not exist for immutable classes. Writing immutable classes for your clients also simplifies client code development—the client code's author need not be concerned with messy aliasing problems. This simplifies not only development, but also testing of the client code, as we'll see below.

For our purposes, the ideal form of a class is one with only final fields to immutable objects. This guarantees that an instance of the class can never change. The Group class above is an example of such a class.