Software Testing Basics: What to Test and When

Tests do not guarantee bug-free code, but they catch regressions before users do — and sleep is underrated.

Testing means writing code that checks your code. Run tests before merge; if something breaks, you know before customers tweet about it. No team has infinite time — the art is picking the right layers.

Unit tests cover small pieces — one function, one class — in isolation. Fast, cheap, run on every save in many setups. Mock external services so failures point to your logic, not a down API. If math or parsing is critical, unit tests pay for themselves quickly.

Integration tests check components together — database queries, API routes, payment flow with a test card. Slower but catch wiring mistakes unit tests miss. A few happy-path and sad-path integration tests beat a hundred shallow unit tests that mock everything.

End-to-end (E2E) tests drive the app like a user — click login, add to cart, checkout. Tools like Playwright, Cypress, and Selenium shine here. Flaky E2E is a curse; keep the suite small and focused on revenue-critical paths.

Manual testing still matters for UX, visual polish, and "does this feel right?" Automate repetition; explore new features with human eyes. Test on real devices for mobile — emulators miss gestures and keyboard quirks.

Start where pain is highest. Greenfield project? Unit tests on core logic plus one E2E smoke test. Legacy mess? Add tests only when you touch code — "boy scout rule." CI should run tests on every PR. Red build means do not merge. Simple rule, enormous impact over a year.