Beautiful Testing

Automating Tests

After a few weeks of research and discussion, the team decided that going forward we’d write all new code in a layered architecture, designed with automated testing in mind. As with many (if not all) teams new to TDD, our programmers found it hard to write unit tests for the legacy code, where business and presentation logic was mixed up with database access. In fact, it was just hard to do TDD, period. Brian Marick refers to this phenomenon as the “Hump of Pain” (see Figure 15-2). As the team became proficient in TDD, the programmers started writing unit tests whenever they changed legacy code, as well as when they coded in the new architecture.

Figure 15-2. The Hump of Pain

My team liked Mike Cohn’s “test automation pyramid” idea (Figure 15-3). We knew our best return on investment (ROI) would be from automating tests at the unit level. We were keen to do the bulk of our functional test automation “behind” the GUI, and had chosen FitNesse as the tool to accomplish this.

Figure 15-3. Test automation pyramid

Our immediate problem was a huge, buggy legacy system where the presentation, business logic, and database layers were intertwined. The fastest way to get some automated regression test coverage was through the GUI. But GUI tests are notoriously brittle and hard to ...