Java Reference
In-Depth Information
The
TestRunner
will use introspection and reflection to dig information
out of the
AccountTest
class. It will find all the public methods that begin
with
test
and have no parameters. It will execute
setUp()
, then one of the
test methods, then
tearDown()
; then
setUp()
, then another test method,
then
tearDown()
, and so on. Our example has only one test method,
testCreateSub()
, so that will be the one test method it runs.
The result of running the test should look like this:
$ java junit.textui.TestRunner net.multitool.core.AccountTest
.
Time: 0.071
OK (1 test)
$
13.6
R
UNNING
T
EST
S
UITES
Quite likely, you'll want to run several tests, exercising the various classes that
make up your application. Let's see an example of how to build such a suite of
tests (Example 13.3).
While not defined as an interface, the convention is used by JUnit
TestRunner
classes that they will look for a public static method called
suite()
in any class that you ask a
TestRunner
to run. Your class, the one
that will define the suite of tests, should return something that implements the
Test
interface. A
TestSuite
object is one such object, and we can fill it with
tests gleaned automatically by JUnit from the class names that we supply.
We've also added a
main()
that invokes the text-based user interface for
running these tests. That way you can invoke the tests from the command line
if you like.
Here are the two commands to compile and execute the
CoreTest
suite,
using the Swing GUI:
$ javac test/net/multitool/core/CoreTest.java
$ java junit.swingui.TestRunner net.multitool.core.CoreTest
When the GUI runs, click on the
Hierarchy
tab and you can see the vari-
ous tests that make up the suite. Opening the folders will show the tests inside
of suites (Figure 13.4).
