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 ...
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.