Test the Promise, Not Just the Code

A software test is most useful when it protects a promise someone relies on—not merely a line of code that happens to pass.

For one important service behavior, try a small continuity test:

• Name the user outcome that must remain dependable.
• Check the normal path and one likely failure or recovery path.
• Record who reviews the test when the behavior changes.

That last step matters. An unmaintained test can become another brittle dependency—or keep an outdated behavior alive just because it is familiar. Keep the test only while it gives the team useful evidence about quality, and revise it when the promise changes.

What user-facing behavior in your work deserves that kind of protection?