Java Reference
In-Depth Information
It prints a period for each test that it runs. (Yes, there are 119 periods
there. Go ahead; count them if you must.) The command-line version is useful
for incorporating JUnit tests into shell scripts (e.g., for testing nightly builds,
e-mailing the results) and is used by
ant
when it invokes JUnit.
13.5
W
RITING
T
EST
C
ASES
Writing a test case for your own Java code consists, at its simplest, of writing a
new class for each class that you want to test. But this class that you create is
built in a special way so that the test harness of JUnit can execute it. That is,
the test case class that you create should meet certain naming conventions, so
that the JUnit test runners can find what they need in order to run your tests.
More specifically, your test cases will extend the JUnit class
TestCase
.
Now,
TestCase
is an abstract class, meaning there are parts that you have to
fill in (i.e., methods that you must write) to make it a working class. Moreover,
TestCase
implements (in the Java sense of the word) the
Test
interface. Can
you begin to see how the
TestCase
class is a framework? It defines the rough
outline of how the test cases will look so that a common test runner can run
any test case, no matter who wrote it.
Let's look at a simple example, to see what such a test case looks like.
Example 13.2 shows one for testing our
Account
class.
Example 13.2
Simple test case
package net.multitool.core;
import java.util.*; // needed by our class
import net.multitool.util.*; // needed by our class
import junit.framework.*; // needed by JUnit
/**
* for JUnit testing of Account.java
*/
public class
AccountTest
extends TestCase
{
// our test instrumentation:
Account base;
