If you focus on refactoring the system under development, and do only the minimal amount of refactoring of tests, your system will be harder to change than it needs to be. You put a lot of effort into giving your system the best design you can; if you neglect to update your tests, it will leave your system harder to change, riskier to extend, more difficult to test, and less clear than it can be.

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.

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.