Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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
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};
c.setPar(par);
Par for hole 1 and 2 is obviously 4+4=8, so we can program a test like
this:
if (c.parUpToHole(2) != 8) {
System.out.println(
"*** 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) {
System.out.println(
"*** Error in Course.parUpToHole: par for 0 holes not 0");
}
if (c.parUpToHole(2) != 8) {
System.out.println(
"*** Error in Course.parUpToHole: par for 2 holes not 8");
}
if (c.parUpToHole(18) != 72) {
System.out.println(
"*** 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.
