24. Everything You Do Not Test Is Broken!

This is probably my oldest "tile." I used this line very early in my career — and it's still absolutely true. Just assume that everything you didn't test is broken until you prove otherwise. So test EVERYTHING.

By "everything," I don't just mean the happy flow (which most developers cover), but especially what happens when the flow goes sideways. Think about:

• the user goes back or refreshes halfway 🔁;
• the user jumps into the flow via a deep link;
• clicking a button many times (or too early) 🖱️; clicking before things have loaded;
• unexpected characters, emoji, RTL text, or very long strings 🔤;
• slow or flaky network (offline/online), timeouts 📶;
• expired sessions/tokens, changing permissions/roles 🔒.

Adding a new feature? Don't only test the new functionality — test the existing parts as well. I can't count how often I've heard, "this really can't break anything else," only to watch it… break something else.

Because testing all these edge cases can be a lot of work, it's smart to add automated tests. They save tons of time. But beware: no matter how broad they are, automated tests are never a replacement for real, hands-on testing. Always check your own application yourself.

And yes, you can throw everything over the fence to QA or hope the client will test it. But bugs others find still count as your bugs 🐛. That costs trust and hurts your reputation — and your client may start looking for a different partner.

Do you always test everything? Or do you sometimes think, "it'll probably be fine"? I'm curious about your approach and pitfalls — share them below 👇

Want to scale your testing strategy (unit/integration/E2E/contract/a11y) or make your CI reliable and fast without flakiness? I help teams pragmatically and hands-on. DM me. 🚀