A Small Test Strategy That Catches Real Bugs

TESTING STRATEGY — Web form -> server endpoint -> DB write 1) UNIT TESTS Scope: one function/class in isolation, all dependencies mocked (DB, HTTP, framework). Concrete idea: test the endpoint's validation function. Feed it a payload with a missing required field, an over-length string, and a malformed email; assert it returns the right error messages and never calls the DB layer. Mock the DB module entirely. What NOT to test: the framework's routing, the real DB driver, SQL syntax, or third-party libraries. If you mock the DB, you are NOT testing the DB — that's fine, that's the point. Don't assert implementation details like "validate() was called" unless it buys you something. 2) INTEGRATION TESTS Scope: real server + real database (usually a test DB or transaction-rolled-back DB), but no browser. Exercise the actual HTTP endpoint against the actual DB. Concrete idea: POST a valid form payload to the real endpoint, then query the test database directly and assert a row exists with the correct values (and that the ID/created_at fields were populated by the server, not the client). Also POST an invalid payload and assert no row was written. What NOT to test: rendering/UI behavior, JavaScript in the browser, or anything visual. Also don't test against production data or a shared dev DB — use a dedicated test database with fast teardown. Don't re-verify things the unit tests already covered. 3) BROWSER TESTS (E2E) Scope: full user journey in a real browser (Playwright/Cypress) against the running app + DB. Concrete idea: load the form page, fill every field, submit, and assert the success page appears AND the new record shows up in the list/confirmation view (the user-visible confirmation that the write happened). Optionally assert the DB row exists too. What NOT to test: every validation edge case (that's unit/integration territory — browser tests are slow and flaky), CSS pixel-perfection, or things that depend on network latency/third-party services. Keep browser tests to a few happy-path journeys plus one or two critical failures. QUICK RULES - Unit = fast, many, no I/O. Integration = real I/O, medium count. Browser = few, slow, most valuable per test. - Test the boundary you own: validation at unit level, persistence at integration level, user-visible outcome at browser level. - Don't duplicate coverage across layers; each layer tests a different failure mode. - Never test the framework, the DB vendor, or the browser itself.