Fullstack testing strategies: from unit tests to E2E and beyond

A good testing strategy gives you confidence to deploy frequently and refactor aggressively. A bad testing strategy gives you slow builds, flaky tests, and false confidence. The difference is in how you choose what to test and at what level.

Follow the testing trophy, not the testing pyramid. The testing pyramid recommends many unit tests, fewer integration tests, and even fewer E2E tests. The testing trophy flips this: invest most in integration tests that test your application the way users use it, with unit tests and E2E tests as complements.

Unit tests are for logic, not plumbing. Test pure functions, business logic, and utility functions that have complex behavior. Don't write unit tests for trivial getters, setters, or code that your type system already validates. Unit tests should be fast and deterministic.

Integration tests should test your application's core paths with real dependencies. For a web application, this means spinning up the server, hitting APIs with real HTTP requests, and asserting on the response. Use test databases and mock external services. Integration tests give the highest confidence-to-effort ratio.

E2E tests are for critical user journeys. Test signup, login, checkout, and the primary value-adding flow of your application. Keep your E2E suite small 5-10 tests for most applications. E2E tests are slow, flaky, and expensive to maintain. Use them sparingly for the flows that must not break.

Use your test suite to guide your architecture. If something is hard to test, it's probably hard to use correctly. Difficult testing often reveals design problems: tight coupling, global state, or unclear responsibilities. Fix the design, not the test.

Run your fastest tests first. Fail fast in CI. Unit tests should run in seconds. Integration tests should run in minutes. E2E tests should run in a separate CI stage after the faster tests pass. This gives developers the fastest possible feedback on their changes.

Treat flaky tests as emergencies. A test that passes and fails without code changes is worse than no test it erodes trust in the test suite. When you find a flaky test, fix it or delete it immediately. A test suite with no flaky tests is a test suite the team trusts and relies on.

-

Rizwan Saleem | https://rizwansaleem.co