It’s common for the build
time in big embedded projects to take hours—a cell phone
manufacturer I worked with had a six-hour build.
But, the edit/build/unit test cycle time must be
measured in seconds, not minutes or hours. To get into a TDD
rhythm, you need a fast incremental build—you don’t need
to build the whole system for TDD. You can build parts of the
system independently when dependencies are managed.
If your build time is too long, you will probably need
multiple unit test builds to keep the incremental
build time down. Multiple unit tests builds should not
be too difficult to set up, because your product likely
already has some structure based around libraries,
components, and subsystems. The exact mechanics of
setting up each build depend on your development
environment and the unit test harness being used. In
essence, you set up different make files or different
make targets to generate the different test
executables.
The real challenge with testing modules, or groups of modules
together, is that you need modular code! The all too prevalent
data structure and function call free-for-all antipattern makes
breaking the system apart for testing more difficult. Starting
in the next chapter, we will look at techniques for breaking
dependencies that can help in creating smaller, more focused
test builds.
