Five checks before a PR is actually done
A practical checklist for separating a demo-ready pull request from one that survives contact with real users.
Hammad Iqbal
Software Engineer
"It works on my machine" is rarely a lie — it's just an incomplete test. These are the five checks that catch the gap between a PR that passes review and one that holds up in production.
- Test the failure path, not just the success path.
- Check what the UI does with zero items, one item, and a thousand.
- Confirm the change is safe to roll back on its own.
1. What happens when the request fails?
Every network call has a failure branch. If the only way to see it is to physically disconnect Wi-Fi mid-test, it hasn't really been tested. Throttle the connection, force a 500 from the dev tools, and watch what the user actually sees.
2. Does it handle the empty and extreme states?
A list component tested with three sample rows tells you almost nothing about how it behaves with zero rows, or with three hundred. Empty states and overflow are where most UI bugs live, and they're the states least likely to appear in a staging seed script.
3. Can this be reverted without a second deploy?
If shipping the change also means shipping an irreversible migration, that's worth flagging in the PR description, not discovering during an incident. Feature flags and additive migrations turn a risky release into a boring one.
4. Is there a test that would catch this breaking again?
Manually verifying a fix confirms it works today. A regression test confirms it still works after the next three people touch that file. If the bug was subtle enough to ship once, it's subtle enough to ship again without one.
5. Would this make sense to someone with no context?
Six months from now, the PR description is the only thing that explains why a workaround exists. A one-line comment on the non-obvious part saves the next person — often you — from re-deriving the reasoning from scratch.
None of these checks are expensive. They're worth running before requesting review, not after a bug report lands.
Have a project this kind of thinking applies to?
Tell me what you're building — I read every message myself.