That assumes (1) that if you’re alerted, the non-local impact is no longer expensive and (2) that the test suite really will alert you to all the important non-local impacts.

I think both of these are simply false in practice, most of the time.

Knowing that a non-local effect exists isn’t the battle–dealing with it is. You’re pushing back the assumption that changes are cheap and easy.

And sometimes even a “good” test suite simply won’t expose all the important non-local impacts.

If you’re worried about non-localized impact, you can chose to handle it manually – exponential cost driven by the number of paths your software can take. (With the implication that, sooner or later, modifications to software are commercially unfeasible!)

Or, you can do what every other industry did when a process became to costly to do manually: Automate – i.e., a test suite.

It still doesn’t solve the problem completely – test suites are still to some extent incurring exponential cost – but you’ve flattened the curve enough to make it almost flat for even large projects.

(There are other things that impact the curve, choice of language for example. But it still remains flattened )

And that means you will be alerted to any non-local impacts your change has the moment you make it. Changing software is *not* expensive unless we make it so.

Refactoring plays another significant part here. If you let your code grow into a tangled mess, more and more of the impact is non-local. So you need to clean it up regularly.

(And a unit test suite doesn’t count as one to me unless it runs every time I type command-B in Xcode, and it’s trivial to add new tests to…)

Test-driven development isn’t a panacea. But I’ve found that it works far better than any other technique I’ve tried.