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 ...
Get Beautiful Testing now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
