Testing strategy — pyramid, trophy, patterns (draft)

Draft — umbrella note for how I think about automated testing before diving into React-specific tooling in React testing and quality attributes in Non-functional testing. I have slide decks on this; when I recover them I’ll tighten examples and citations.

Test pyramid (classic)

The test pyramid (Mike Cohn–style) argues for many fast, isolated tests at the bottom (unit), fewer integration tests in the middle, and very few slow, expensive E2E tests at the top. The intent is feedback speed and flakiness control: cheap tests run on every commit; expensive tests run when the lower layers are green.

Testing trophy (frontend tilt)

Kent C. Dodds’ testing trophy pushes Integration and static checks (types, lint) as the center of gravity for UI work: more confidence per test than ultra-isolated unit tests that over-mock the DOM. It’s not a contradiction with the pyramid—it reframes where you want density for React apps.

Good patterns (working list)

• Test behavior, not implementation — selectors and assertions that survive refactors.
• Clear boundaries — know what is unit vs integration vs E2E for this repo.
• Deterministic data — factories, fixed clocks, controlled network in integration tests.
• Fail one reason at a time — parallel jobs in CI (lint, types, unit, E2E) instead of one opaque script.

Anti-patterns (working list)

• E2E as the only safety net — slow, brittle, hard to debug.
• Mocking the universe in unit tests — tests that only prove mocks agree.
• Flaky waits — sleep instead of conditions; shared mutable global state between tests.
• Testing third-party widgets — assert your integration contract, not their internals.

Next

Link out to concrete stacks: React testing, CI shape in GitLab CI for a frontend, and Non-functional testing.