This is a neat observation. One equivalent to test-Driven Development (TDD) when working with an existing codebase might be “test-driven refactoring”. The idea seems to be that at any particular point in the lifecycle of a software system not all of the benefits of TDD are actually being used. So why not just do enough TDD to get the required benefits at the time.
In this case the need is to refactor some existing code in preparation for a change. Rather than either (a) stop to write tests for the whole system, or (b) throw up our hands and abandon TDD for this work, the suggestion is to write a passing test around the exact code being refactored, then use that test to ensure that the change preserved that behaviour. Then, in the TDD style, rinse and repeat for the following refactorings.
As this progresses the result should be a growing body of regression tests. concentrating around the areas which have actually changed, which seems good to me. It’s not as good as TDD from the start, but it’s better than no tests at all.