The Impact of Refactoring on Tests
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Roles of Automated Tests
Automated tests support a number of goals:
Assuring us that a system does what it's intended to do
Supporting refactoring by catching mistakes in manual refactoring
Helping to design the system (when using test-driven development)
Documenting the way in which internal parts of the system are used
There are different ways to classify automated tests. Figure 1 arranges them by role. In Figure 1, customer refers to a team that may include testers and other specialists; programmer refers to the group consisting of various types of developers.
)
Figure
1 Tests and their owners.
Customers own the highest-level tests (including system tests, performance tests, and so on). Customers implement some of these tests themselves; for example, by specifying test data and expected results in a spreadsheet. At other times, they get the programmers to implement the tests; for example, from hand-written notes.
Customer tests are supported by a set of test fixtures that let people specify tests at a natural level of detail. Fixtures are on the border of ownership, in that customers and programmers have to negotiate their meaning. Programmers can implement fixtures in any convenient language. Fixtures usually connect to facades or other high-level classes, as customer tests usually test some end-to-end feature.
Programmers own and implement their own tests as well. These are typically class, unit, subsystem, and other tests. In test-driven development, this group includes the tests that drove the code to be written. The specifics of programmer tests depend on how the system is implemented.