We Have a Long Build Time

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.