Have you ever found yourself adding a new feature to a large code base, where it seems every little change causes three new things to break?

In such a situation, how do you know when you’re done? How do you know that you’ve tied up all the loose ends?

I’m working on two projects these days. For one client, I’m updating an old, buggy PHP application from PHP7 to PHP8. And it seems that every fix causes three more breaks, like unraveling a sweater by pulling a loose thread. The testing team is quite busy validating every fix I make, and frequently pointing out new problems they discover.

In another project, my open-source library, I’ve recently experienced something similar working on some API changes. The main difference is that this project has very thorough test coverage.

Just a day or two ago, I was working on one of these API changes, going through the rote process of updating every bit of code that was affected, when suddenly… all the tests started passing.

Perhaps as a result of an emotional hold-over from the PHP project I’m working on for the client, I felt a sense of anxiety. “What’s broken that I can’t see??”

Then I realized: “Nothing!”

Yes, there may be (in fact, almost certainly are) some lurking bugs that aren’t tested. Tests cannot prove the absense of bugs, after all.

But, I could rest assured that the code did what I expected it to do, in virtually all considered cases.

I find that when I’m working on a project that relies on manual verification of changes, I’m literaly never confident. I never feel sure of the work I’m doing.

When I have good tests, on the other hand, I can rest much easier. I can know with actual certainty, when my work is done.