Java Reference
In-Depth Information
concept in the sense that
JU
nit tests are unit tests, that is, they test a single component
of your project in isolation. A great many of the projects out there, however, have mod-
ular architecture, where different developers on the team work on different modules of
the project. Each developer takes care of developing their own module and their own
unit tests to make sure their module is well tested.
Modules interact with each other, so we need to have all the different modules
assembled to see how they work together. In order for the application to be test
proven, we need another sort of test: integration or functional tests. As you already
saw in chapter 3, these tests test the interaction between different modules.
But almost always integration tests are time consuming, and as a single developer
you may not have all the modules built on your machine. Therefore, it makes no sense
to run all the integration tests during development. That's because at development
we're focused on only our module, and all we want to know is that it works as a single
unit. During development we care mostly that if we provide the right input data, the
module not only behaves as expected but also produces the expected result.
Test-driven development taught us to test early and test often. Executing all our
unit, integration, and functional tests every time we make a small change would slow
us immensely. To avoid this, we execute at development time only the unit tests—as
early and as often as reasonable. What happens to the integration tests?
11.1.1
Continuous integration testing
Integration tests should be executed independently from the development process.
The best way is to execute them at a regular interval (say, 15 minutes). This way, if
something gets broken, you'll hear about it within 15 minutes, and there's a better
chance for you to fix it.
DEFINITION
1
Continuous integration (
CI
)
—Continuous integration is a software
development practice whereby members of a team integrate their work fre-
quently. Usually each person integrates at least daily, leading to multiple inte-
grations per day. Each integration is verified by an automated build (including
a test) to detect integration errors as quickly as possible. Many teams find that
this approach leads to significantly reduced integration problems and allows
for the development of cohesive software more rapidly.
To get the integration tests executed at a regular interval, we also need to have the
modules of the system prepared and built. After the modules are built and the inte-
gration tests are executed, we'd like to see the results of the execution as quickly
as possible.
1
This definition is taken from a marvelous article by Martin Fowler and Matthew Foemmel. It can be found
