Information Technology Reference
In-Depth Information
Typically, the majority of a build's runtime is spent on tests, and the
longest tests are those with dependencies on outside objects such as
databases, file systems, and Web containers. Unit tests require the least
setup (by definition, none), and system tests need the most (every-
thing). By defining and grouping tests by type—unit, component, and
system—development teams can fashion a build process that runs
test
categories
rather than a gigantic test task that runs everything at once.
Unit tests run most often (with every commit); component tests, sys-
tem tests, and functional tests can be run with secondary builds or on
periodic intervals.
Unit Tests
A true unit test should run to completion (successfully) in a fraction of
a second. If a unit test takes longer, take a close look at it—it's either
broken, or instead of being a unit test, it is really a component-level
test. The XP mantra of “test a little, code a little, test a little…” is pred-
icated on the notion of rapid testing. If unit testing takes enough time
that the developer can focus on something else, it's taking too long. It
will become a burden, and will soon become something to avoid
instead of depend on.
In a CI environment, builds are run any time someone applies a
change to the version control repository; therefore, unit tests should be
run each time someone checks in code (called the
commit build
).
There is little configuration cost, and the resource cost to run them is
negligible.
Component Tests
Component tests, which usually have multiple dependencies, take a bit
longer to run. As such, they should be run as part of secondary builds
or periodically; regardless, they should be run before committing code
into a repository (in your private build). As we covered in Chapter 4,
component tests can be run as part of a secondary, and more “heavy-
weight,” integration build that follows the commit build. Component
