Java Reference
In-Depth Information
We need a software tool to do all of the following steps automatically:
Check out the project from the source control system.
1
Build each of the modules and execute all of the unit tests to verify that the dif-
ferent modules work as expected in isolation.
2
Execute integration tests to verify that the modules integrate with each other in
the expected way.
3
Publish the results from the tests executed in step 3.
4
Several questions may arise at this point. First, what's the difference between a human
executing all these steps and a tool doing so? The answer is, there's no difference and
there shouldn't be! Apart from the fact that no one can bear doing such a job, if you
take a close look at the first item in the list, you'll see that we check out the project
from the source control system. We do that as if we were new members of the team
and just started with the project—with a clean checkout in an empty folder. Then,
before moving on, we want to make sure that all of the modules work properly in iso-
lation, because if they don't, it makes little sense to test whether they integrate well
with the other modules. The last step in the proposed scenario is to notify the devel-
opers about the test results. The notification could be done with an email, or an
ICQ
message, or by publishing the reports from the tests on a web server.
This overall interaction is shown in figure 11.1. The
CI
tool interacts with the
source control system to get the project (1). After that it uses the build tool that your
project is using, builds your project, and executes different kinds of tests (2 and 3).
Finally (4), the
CI
tool publishes the results and blows the whistle so that everybody
can see them.
The four steps are general and could be greatly improved. For instance, it would
be better to check to see if any changes have been made in the source control system
Figure 11.1
Continuous integration scheme
