Testing Pyramid

• · TP1 — Unit tests form the bulk of the suite: pure functions, business logic, utilities, isolated component behavior — fast (milliseconds), run on every save.
• · TP2 — Integration tests cover component boundaries (API endpoint + database, service + external client) at a moderate volume — verify the seams unit tests can't.
• · TP3 — E2E tests cover only critical user journeys (signup, checkout, core task completion) — few in number, each expensive to write and maintain.
• · TP4 — Flaky tests are fixed or removed immediately, never left "usually passing" — a flaky test is worse than no test.
• · TP5 — Test layer choice matches what's being verified: business logic → unit; "do these two systems talk correctly" → integration; "can a real user complete this flow" → E2E.

• · Count the suite's tests by layer — if E2E outnumbers unit tests, that's an inverted pyramid worth addressing.
• · A bug found in production → ask "which layer should have caught this?" and add a test at the *cheapest* layer that would have caught it, not reflexively at E2E.
• · A flaky test → fix its root cause (timing, test isolation, shared state) within the sprint, or quarantine/remove it — don't let it linger "usually green."
• · CI taking many minutes → check the layer distribution; often a few slow E2E tests dominate runtime disproportionately to their coverage value.

• · Ice cream cone — mostly E2E tests, few unit tests; slow, flaky CI, hard to pinpoint failures.
• · Ignored flaky tests — a test that fails ~10% of the time, re-run until green, normalized as "just flaky" instead of fixed.
• · Testing implementation, not behavior — unit tests asserting internal implementation details that break on every refactor even when behavior is unchanged.
• · E2E-only bug regression tests — every production bug gets one slow E2E test instead of a fast unit test at the actual fault layer.
• · No integration layer — only unit tests (mocking everything) and E2E tests (testing everything), missing the "do these two real components actually cooperate" layer where many real bugs live.

• [ ] New business logic has unit test coverage. (TY1)
• [ ] API/service boundaries have integration tests. (TY2)
• [ ] Flaky tests fixed or quarantined, not left intermittent. (TY4)
• [ ] E2E tests limited to critical journeys, justified when added. (TY3)
• [ ] Suite shape (unit/integration/E2E ratio) roughly pyramid, not inverted.
• [ ] CI reports layer breakdown for visibility.

• The Practical Test Pyramid

Este pack cita las siguientes fuentes registradas en el índice bibliográfico:

• blogTestPyramidMartin Fowler
• blogThe Practical Test PyramidHam Vocke, via martinfowler.com