Unit Testing Java Programs

Enter JUnit
The Round class
Collecting your test cases

by Keld H. Hansen

Testing programs can be very boring. Especially testing other people's programs. And especially if you're a programmer. But programmers love to write programs, so why not let the programmers write some programs that'll do the testing for them? This is the idea behind automated testing, and this is what this article is about.

Automated unit testing (a unit typically being a Java class) is not a new thing. Some of us did it years ago on the mainframes, and it's as useful as ever. What distinguishes automated unit testing from writing and running ad hoc test programs is this:

  • you can easily run your unit test again and again (this is also called regression testing)
  • you have a "framework" that facilitates the testing--it might actually run the test automatically whenever you build (i.e. compile) or deploy your application

When unit testing is implemented the right way it helps the programmers to become more productive, while at the same time increasing the quality of the developed code. It's important to realize that unit testing should be part of the development process, and that code must be designed so it can be tested. Actually the trend today is to write the unit test code before the code to be tested, to put focus on the interface and behavior of your Java classes. In this article however, we want to simplify the subject, so the code to be tested already exists.

Playing golf

To show how automated testing is done we'll look at a "real life situation"--let's play some golf! Our business case is this: we would like to develop a program that keeps track of the score on a golf course. First we put on our Object Analysis glasses and soon spot these two objects:

  • the Course--with these properties:
    - the name of the course
    - the "par" for the course (the ideal number of strokes for each hole)
  • the Round--symbolizing a player's round on a given course--with these properties:
    - the name of the player (should be an object, but we keep things simple for the example)
    - the course
    - the strokes used for each hole on the course

When a player is on the course we would like to keep track of his score, which we define as the number of strokes above or below the par of the course. So if the par for the first two holes are 4 and 5, and the player used 4 and 6 strokes, the score is 1 ("one above par").

The Course class

The name of the Course we implement as a String, and the par as an int array. Besides setter- and getter-methods, we'll need a method that returns the ideal number of strokes up to hole number "n". Let's call it "parUpToHole(int n)". Here's my suggestion for the class:

package hansen.playground;
import java.util.*;
public class Course {
  private String name; // name of course
  private int[] par; // the par for each hole 
  * Set the name of the course
  public void setName(String name) {
    this.name = name;
  * Set the par for the course
  public void setPar(int[] par) {
    this.par = par;

  * Get the number of holes for the course
  public int getNumberOfHoles() {
    return par.length;
  * Return the par for a given hole
  public int parForHole(int hole) {
    return par[hole-1];
  * Return the par from hole 1 and up to a given hole
  public int parUpToHole(int hole) {
    int sum = 0;
    for (int i = 0; i < hole; i++) { 
      sum += par[i];
    return sum;

To simplify the examples we have not included checking for usage errors (like calling "getNumberOfHoles" before calling "setPar").

Testing the Course class

Using the methods in class "Course" we can now sketch a program that will test if "parUpToHole" works as it should. Let's assume that the Course is the famous St. Andrews in Scotland:

Course c = new Course();
	c.setName("St. Andrews");
	int[] par = {4,4,4,4,5,4,4,3,4,4,3,4,4,5,4,4,4,4};

Par for hole 1 and 2 is obviously 4+4=8, so we can program a test like this:

if (c.parUpToHole(2) != 8) {
  "*** Error in Course.parUpToHole: par for 2 holes not 8");

If we run the program and the error message is written out, we have a bug to fix (or a bug in our test program!). If the program runs silently all is OK.

You could write a test for each of the 18 holes, but most programmers would be satisfied by testing the limits--0 and 18 holes--and something in between, for example 2:

if (c.parUpToHole(0) != 0) {
  "*** Error in Course.parUpToHole: par for 0 holes not 0");
if (c.parUpToHole(2) != 8) {
  "*** Error in Course.parUpToHole: par for 2 holes not 8");
if (c.parUpToHole(18) != 72) {
  "*** Error in Course.parUpToHole: par for 18 holes not 72");

This is not the most elegant way of writing a test program. The essential thing is however, that you want to compare some values, and then according to the result take some action. By writing this test program we may automate the unit test of "parUpToHole", and by running the program we can be pretty sure that this method works as it should.

But we can do better than this...

0 Comments  (click to add your comment)
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



About | Sitemap | Contact
We have made updates to our Privacy Policy to reflect the implementation of the General Data Protection Regulation.