Java Reference
In-Depth Information
While it is not necessary to understand the steps that are being performed at this
point, we will go over them quickly so that you have some idea of what is happen-
ing as the messages fly by on the screen.
The first step is required to make sure that previous builds do not affect the
current build—each time you run it, it starts with a clean slate.
The second step is obvious (the code has to be compiled), but the third one
may not be. What happens here is that the compiled code is copied and instru-
mented by a coverage-tracking tool called
EMMA
. This will be explained shortly.
Next, the unit tests are run over the framework components. As mentioned
earlier, this is to verify that the components work as expected at a low level (i.e.,
when you call a method with known inputs, you see the expected results).
The compatibility tests are used to verify that users who are using version 1.
x
of the framework are able to replace it with version 2.
x
without rewriting their
application.
The reports generated by the build process are intended to provide two
pieces of information: first, the JUnit report shows the tests that were run and
whether or not they were successful. The entry point for those reports is
reports\junit\index.html
(relative to the build directory), and is useful when
you are making changes to the framework and want to see if the tests were
successful. The second report, which is located at
reports\coverage\co-
verage.html
, shows coverage for the tests that were run.
Code coverage
is a measure
used in software testing that describes the degree to which the source code of a
program has been tested. In other words, it shows how effective the tests were.
The coverage reports show four statistics:
Class coverage
—Which classes have been tested?
■
Method coverage
—Which methods have been tested?
■
Block coverage
—Which blocks of code have been tested?
■
Line coverage
—Which lines of code have been tested?
■
If you do make a change in the framework, be sure that that you check the test
reports to make sure that the existing tests are successful and that the unit tests
have been modified to adequately test your change. Once that is done, feel free to
upload the changes to the Apache issue-tracking system (
JIRA
), and if it is some-
thing that needs to be added to the framework, one of the committers will try to
include it in the next distribution.
So, now that you built a distribution, what do you have? Read on to find out!
