Why Testing Actually Matters
We don’t write tests to satisfy a manager or hit a 100% coverage metric. We write tests for one reason: to modify code at 4:00 PM on a Friday without fear. If changing a database query or a UI component gives you anxiety, your architecture is controlling you. A great testing suite is a safety net that transforms software maintenance from a high-stress gamble into a predictable, confident routine. But to get there, you have to run the right tests in the right places.
The Strategy: What to Test and Where
Not all code is created equal, so it shouldn’t be tested the same way. We divide testing into four distinct layers, moving from isolated code to the complete user experience.
1. Unit Tests: Pure Business Logic
- The Rule: Test pure functions that calculate, transform, or format data.
- Where to use: Date utilities, string formatters, mathematical trend calculators, and schema validation helpers.
- Why: They execute instantly in system memory. If you pass input $A$, you must get output $B$. There are no network requests, databases, or third-party APIs allowed here.
2. Integration Tests: Infrastructure & Contracts
- The Rule: Test code whose primary job is to interact with an external service.
- Where to use: Database repositories (D1/SQL), cache mechanisms (KV), and background event workers (Queues).
- Why: Unit testing a database repository with a fake mock is useless. You need to know if your actual SQL query runs correctly. Use a local, in-memory database to seed real data, execute the query, and assert the real database results.
3. End-to-End (E2E) Tests: The Critical User Paths
- The Rule: Test the entire system working together by simulating a real user in a headless browser.
- Where to use: Core business funnels only—like user registration, authentication flow, and checkout.
- Why: E2E tests are slow and expensive to run. Don’t use them to test small edge cases. Use them to guarantee that a user can successfully log into your dashboard and see their analytics tracking script link.
4. Manual Testing: Exploratory & Visual Polish
- The Rule: Use human eyes for things machines are terrible at evaluating.
- Where to use: User interface layout shifts, micro-animations, responsive design on physical hardware, and UX feeling.
- Why: A script can check if a button exists in the DOM, but it cannot tell you if that button feels awkward or looks broken on a specific mobile screen configuration.
The Summary Blueprint
| Test Type | What it Targets | Environment | Speed | Cost to Maintain |
|---|---|---|---|---|
| Unit | Isolated calculations & logic | Pure RAM (No I/O) | Lightning Fast | Very Low |
| Integration | DB queries, APIs, Caches | Local Docker / Memory | Fast | Medium |
| E2E | Complete critical user flows | Headless Browser | Slow | High |
| Manual | Visual polish & UX intuition | Human Interface | Very Slow | High |
By structuring your suite this way, you stop wasting time writing brittle mocks for your repositories and avoid creating slow, flaky E2E tests for basic code logic. Test with purpose, keep your runner fast, and build software that is built to scale.