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

Test for fun and profit, Part 2: Unit testing

Learn the ins and outs of testing in a Java environment

By Todd Sundsted, JavaWorld.com, 07/26/01

Let's face it: we're developers. We want to create, not test. Any testing we do typically consists of taking our creation for a spin around the track and fixing the resulting flat tires. Once we turn the car over to someone else ... well, as they say, Out of sight, out of mind.

Unfortunately, what I've just described is not testing -- it's not even a close cousin. Testing as an endeavor requires intellectual effort and methodical preparation. Remember, successful tests uncover defects. I hope, when you've finished reading, you understand the challenge behind devising successful tests, because you will then understand why testing tools must be both complete (so you can build thorough tests) and as easy to use and unobtrusive as possible (so they don't themselves complicate the process). Next month we'll begin to build a test harness of our own.

Unit testing

Last month you learned a little bit about many different types of tests and testing strategies: unit and component tests, integration tests, system tests, and so on. This month, we'll focus our attention on the first of these: unit (and component) tests.

I think the best way to get a handle on the notion of unit testing is to consider the simplest programmatic unit in a Java program -- a single class.

public
class Foo {
  private
  HashMap _hashmap = new HashMap();
  private
  Service _service = null;
  public
  Foo(Service service) {
    _service = service;
  }
  public
  Handle
  add(Node node) {
    Handle handle = _service.register(node);
    _hashmap.put(handle, node);
    return handle;
  }
  public
  void
  nestedToString(String stringPrefix, StringBuffer stringbuffer)
  throws EvaluationException {
    stringbuffer.append(stringPrefix);
    stringbuffer.append(evalutate());
    stringbuffer.append('\n');
      .
      .
      .
  }
  public
  abstract
  Object
  evaluate()
  throws EvaluationException {
    .
    .
    .
  }
}

Keep that class in mind as we continue our discussion.

Philosophically, unit testing looks at a programmatic unit, such as a class, as a box with a set of inputs and a set of outputs through which all communication between the box and its environment must flow.

Unit testing: The concept

The figure above depicts a class loosely modeled as one such idealized box. Theoretically, we should be able to apply a set of one or more inputs to a unit, observe the outputs in each case, and thereby determine whether the unit is functioning correctly. The unit-test approach thus presents a nice, simple, logically sound model.