Running JUnit tests from Ant - JUnit in Action - page 138

9.1 A day in the life

For unit tests to be effective, they must be part of the development routine. Most
development cycles begin by checking out code from the source code repository.
Before making any changes, prudent developers first run all unit test suites. Many
teams have a rule that all unit tests in the repository must pass. Before starting any
development, you should check to make sure all tests pass. You should always be sure
that your work starts from a known stable baseline.
The next step is to write the code for a new use case (or modify an existing one.) If
you're a test-driven development ( TDD ) practitioner, you'll start by writing new tests
for the use case (for more about TDD , see chapter 5). In general, the tests will show
that your use case isn't supported by not compiling or failing when executed. Once
you write the code to implement (correctly) the use case, the tests pass, and you can
check in your code. Non- TDD practitioners implement the use case first and then
write the tests. Once the tests pass, the developer checks in the code.
Before you move on to code the next feature, you should have tests to prove the
feature works. After you implement the feature, you can run the tests for the entire
project, ensuring that the new feature didn't break any existing tests. If the existing
code needs to change to accommodate the new feature, you should update the tests
first and then make the changes.
If you test rigorously, both to help you write new code ( TDD ) and to ensure exist-
ing code works with new features (regression testing 2 ), you must continually run the
unit tests as a normal part of the development cycle. You need to be able to run these
tests automatically and effortlessly throughout the day.
In chapter 1, section 1.4, we discussed running JU nit from the command line. Run-
ning a single JU nit test case against a single class isn't difficult. But it isn't practical to
run continuous tests in a project with hundreds or even thousands of classes.
A project that's fully tested can have as many test classes as production classes. You
can't expect developers to run an entire set of regression tests every day manually.
Therefore, you need a way to run tests easily and automatically.
Because you're writing so many tests, you need to write and run tests in the most
effective way possible. Ant is the de facto standard tool for building Java applications;
it's an excellent tool for managing and automating JU nit tests.

9.2 Running tests from Ant

Compiling and testing a single class, like the DefaultController class from chapter 3,
isn't difficult. Compiling a larger project with multiple classes can be a huge headache
if your only tool is the javac command-line compiler. When the number of classes
goes up, more classes need to be on the compiler classpath. Usually, in any one build
you'll have changed only a few classes, which leads us to the issue of minimizing how

2

For more about regression testing, see chapter 4.