Ludzie pragną czasami się rozstawać, żeby móc tęsknić, czekać i cieszyć się z powrotem.
However, in the end I’m not
that pleased with it and have ideas that will probably be implemented in
the next edition of the book (or possibly sooner). Feedback
JUnit
Although the testing framework just described allows you to simply and
easily verify program output, in some cases you may want to perform
more extensive functionality testing on a program. JUnit, available at
http://www.junit.org, is a quickly emerging standard for writing
repeatable tests for Java programs, and provides both simple and
complex testing. Feedback
The original JUnit was presumably based on JDK 1.0 and thus could not
make use of Java’s reflection facilities. As a result, writing unit tests with
the old JUnit was a rather busy and wordy activity, and I found the design
to be unpleasant. Because of this, I wrote my own unit testing framework
for Java5, going to the other extreme and “doing the simplest thing that
could possibly work6.” Since then, JUnit has been modified and uses
reflection to greatly simplify the process of writing unit test code.
Although you still have the option of writing code the “old” way with test
suites and all the other complex details, I believe that in the great majority
of cases you can follow the simple approach shown here (and make your
life more pleasant). Feedback
In the simplest approach to using JUnit, you put all your tests in a
subclass of TestCase. Each test must be public, take no arguments,
return void, and have a method name beginning with the word “test.”
JUnit’s reflection will identify these methods as individual tests, and set
up and run them one at a time, taking measures to avoid side effects
between the tests. Feedback
5 Originally placed in Thinking in Patterns with Java at www.BruceEckel.com. However, with the addition of the reflection approach in JUnit, my framework doesn’t make much
sense anymore and will probably be removed.
6 A key phrase from Extreme Programming (XP). Ironically, one of the JUnit authors
(Kent Beck) is also the author of Extreme Programming Explained (Addison-Wesley
2000) and a main proponent of XP.
946 Thinking
in
Java
www.BruceEckel.com
Traditionally, the setUp( ) method creates and initializes a common set
of objects which will be used in all the tests; however, you can also just put
all such initialization in the constructor for the test class. JUnit creates an
object for each test to ensure there will be no side effects between test
runs. However, all the objects for all the tests are created at once (rather
than creating the object right before the test) so the only difference
between using setUp( ) and the constructor is that setUp( ) is called
directly before the test. In most situations this will not be an issue, and
you can use the constructor approach for simplicity. Feedback
If you need to perform any cleanup after each test (if you modify any
statics which need to be restored, open files that need to be closed, open
network connections, etc.), you write a tearDown( ) method. This is also
optional. Feedback
The following example uses this simple approach to create JUnit tests that
exercise the standard Java ArrayList class. To trace how JUnit creates
and cleans up its test objects, CountedList is inherited from ArrayList
and tracking information is added: Feedback
//: c15:JUnitDemo.java
// Simple use of JUnit to test ArrayList
// {Depends: junit.jar}
import java.util.*;
import junit.framework.*;
// So we can see the list objects being created,
// and keep track of when they are cleaned up:
class CountedList extends ArrayList {
private static int counter = 0;
private int id = counter++;
public CountedList() {
System.out.println("CountedList #" + id);
}
public int getId() { return id; }
}
public class JUnitDemo extends TestCase {
private static com.bruceeckel.simpletest.Test monitor =
new com.bruceeckel.simpletest.Test();
private CountedList list = new CountedList();
// You can use the constructor instead of setUp():
Chapter 15: Discovering problems
947
public JUnitDemo(String name) {
super(name);
for(int i = 0; i < 3; i++)
list.add("" + i);
}
// Thus, setUp() is optional, but is run right
// before the test:
protected void setUp() {
System.out.println("Set up for " + list.getId());
}
// tearDown() is also optional, and is called after
// each test. setUp() and tearDown() can be either
// protected or public:
public void tearDown() {
System.out.println("Tearing down " + list.getId());
}
// All tests have method names beginning with "test":
public void testInsert() {
System.out.println("Running testInsert()");
assertEquals(list.size(), 3);
list.add(1, "Insert");
assertEquals(list.size(), 4);
assertEquals(list.get(1), "Insert");
}
public void testReplace() {
System.out.println("Running testReplace()");
assertEquals(list.size(), 3);
list.set(1, "Replace");
assertEquals(list.size(), 3);
assertEquals(list.get(1), "Replace");