Walk through a first iteration with an example team. You will witness the firstunit test, JUnit hooked into the Ant build process, and other attributes that are vital to the process. You will also be introduced to the use of CVS as the version control system and will conclude with the development of a simple deployment target to handle file creation.

Ant can play an important role in testing. By integrating testing into the
build and deployment process, it becomes easier to implement and enforce
ease-of-use considerations and compliance with testing standards. Development
teams will see a marked improvement in quality and can more easily stick to
delivery schedules. Ant plays a key role in merging the testing process with the
build process, to provide a seamless integration of the often-divergent
processes.

Story

Networks Byte Design, Inc., has embarked on a project to implement eMarket,
their new e-commerce solution for sales and marketing. The core project team has
been assembled and is developing the product using XP. So far, the eMarket
project team has collected user stories written by the customer, decided on a
high-level architecture, and implemented spikes to reduce the risks associated
with the technical design decisions. Sandy, the project leader, schedules a
release planning meeting between the development team and the customer to
sort out the user stories in order to create a release plan.

At the meeting, the developers listen to the customer present each story. The
development team divides into smaller groups and assigns a point value to each
story to indicate its expected difficulty. During the meeting, some user stories
are torn up and rewritten, some are discarded entirely, and a few new stories
are added.

The development team returns the stories to the customer with their initial
estimates and anticipated velocity. After seeing the estimates, the customer
begins to define the priorities. The customer determines the order in which the
stories should be implemented, based on the business value and time required to
complete the story. The result of the meeting is that the first release plan is
developed, which was created to get the stories with the highest business value
completed first.

The customer has selected the stories that she wants to have completed in the
first iteration, and puts them at the top of the stack of all the stories. The
developers and customer go over the user stories, and the development team
discusses the technical aspects of the stories and the tasks that need to be
completed. Finally, the developers sign up for tasks for this iteration.

Sandy is concerned with the customer's uncertainty about requirements
related to workflow and usability. She directs the team to focus on the user
interface so that the customer can have an early look at the proposed design and
workflow.

Michael, the lead developer, decides that for the first iteration, they will
use dummy business objects that have their interfaces developed as needed, but
will just return hard-coded data for the time being. The real implementation of
the business objects will occur in later iterations.

Having completed the first release plan and iteration plan, the group begins
work on the first iteration, which is to begin implementing the Web interface
and mocking up the business objects. Each pair of developers will write a unit
test that tests the functionality that they are about to implement. That is
followed by the required class implementation. As new functionality is added to
each class, the unit test is first modified before adding the new functionality
to the class. The developers must run their unit tests each time they build
their code. To do this efficiently, they need to modify the buildfile to handle
unit testing. JUnit, a free open-source tool that integrates easily with Ant, is
selected as the team's unit-testing tool.

The expense of fixing a bug also generally increases as you move along the
development cycle. A bug caught during development is less expensive to fix than
a bug caught during testing. The cost rises dramatically when a bug must be
fixed in a product that has already shipped. The sooner bugs can be detected and
fixed, the less money they cost to fix.

Testing is an important aspect of every development project. Unless the
software can meet the minimal standards for usability, reliability, performance,
requirements, and overall quality, it might never make it to a production
system. All the work spent in planning, design, and coding will go to waste if
the intended audience never uses the system.

With all the emphasis on testing, it would seem that the various forms of
testing would be a major aspect of most software-development projects.
Unfortunately, many projects start out with good intentions but rarely follow
through with those plans. Most people agree on the importance that testing
should play in the project, but testing often is conducted toward the end of the
project, when the schedule for testing becomes severely compacted, sometimes to
the point of becoming ineffective.

To attempt to combat this trend, newer development methodologies, such as XP,
emphasize testing early and often in the process. Many of the techniques for
testing in these methodologies are not new; they are simply changes in the
frequency and schedule of testing procedures. Emphasis is placed on unit
testing, in which developers test the smallest components of the system. These
new concepts are not miracle cures or silver-bullet solutions, but they can help
ensure that the software being developed has been designed and coded with
testing in mind.

Benefits of Automated Testing

Automated testing brings a number of benefits. For one, the tests are
repeatable. When a test is created, it can be run each time the testing process
is launched. Automating testing reduces the fatigue of performing testing
manually, which leads to more consistent results. Also, because the tests are
automated, they're easy to run, which means that they will be run more
often. As new bugs are discovered and fixed, tests can be added to check for
those bugs, to ensure that they aren't reintroduced. This increases the
overall completeness of testing.

Automating the testing process can be as beneficial as automating the build
process. The testing process is based on the concept of being repeatable, which
requires an automated or, at the very least, well-documented process. Some of
the benefits of automated testing are that it

Is a repeatable process

Uses a consistent approach

Follows a documented process

Frees up developer-hours for more profitable tasks

Is expandable and flexible, with changes in code propagated to the
testing procedure faster and more efficiently

Negates the fatigue factor as development deadlines approach because
automated tests will eliminate the stress and workload of manual testing on
developers

Some drawbacks are worth mentioning, of course. Some features don't
easily lend themselves to automated testing. For example, sometimes
automation-testing software can be used to test complex GUI applications, but
often these applications must be tested by hand.

Automated testing is not a panacea for all problems, but it can contribute to
an efficient and effective software development process. Integrating a testing
tool into Ant that wasn't designed to be executed from Ant can require
additional work. This can be accomplished by extending Ant, using BSF scripting,
or using the <exec> task to launch another tool. If the test will
be run frequently, the effort is worth the benefits gained in ease of
testing.

Because it's a repeatable process, automated testing achieves an
important part of the testing process by making it possible to conduct
regression testing, to retest the same scenario again. How many bugs reported by
testing teams cannot be duplicated by the developers? How many bugs are fixed,
yet the tests that are run to check the fixes are insufficient or different from
the original tests? These are the types of issues that regression testing helps
address, and this is why the benefit of repeatable tests is so high.

Consistency issues are easiest to observe in teams with multiple testers and
developers, but even a single tester would rarely conduct the same tests the
same way each time. Automating the process maintains consistency from one run of
the test to the next, regardless of how much time passes between the two runs of
the tests or who is executing the tests.

The best kind of documentation is documentation that does not have to be
written and yet is guaranteed to be correct. In a nutshell, that is a
description of a self-documenting system. The goal is to create readable code.
When the programmer clearly defines the testing goals for the test, someone who
comes along later can easily understand the purpose of the test. This
documentation does not have to be written; it is a beneficial side effect. The
code is guaranteed to be correct because the tests have been executed under
certain conditions and passed. Basically, tests should be as self-documenting as
possible. Most developers don't like to comment the code that's going
into the product. They're even less likely to comment the unit tests that
accompany the product code because they know that the unit-test code won't
go into the product. By developing readable code, the need to heavily comment
the unit tests is greatly reduced.

By automating the testing process, the computer will usually execute the
testing process in less time than it takes a tester to perform manually.
Although the code will take the same time to execute, the prep time and
interpretation of the results will be quicker with the automated process. Also,
because this is a repeatable test, the automated approach becomes even more
beneficial when the tests must be run multiple times. People get tired of
conducting the same tests repeatedly, and will make mistakes, but the automated
processes run consistently each time. Again, manual testing has its place; the
advantage of automated testing is that it can easily catch many of the problems
before manual testing even begins.