2.5Anti-Patterns: When the Shape Is Wrong

The Ice Cream Cone (Inverted Pyramid)

     /───────────────────────\
    /       E2E Tests         \      Many, slow
   /───────────────────────────\
    \   Integration Tests    /       Some
     \─────────────────────/
      \   Unit Tests      /          Few or none
       \─────────────────/
        \  Manual Tests /            Lots
         \─────────────/

Symptoms:

• Test suite takes hours to run
• Most tests are flaky because they depend on the full stack
• Developers do not run tests locally because they are too slow
• Bug localization is poor -- a test fails but you do not know which component caused it
• Adding a new feature requires updating dozens of E2E tests

Root cause: The team wrote E2E tests first (or instead of) unit tests, often because QA was the only team writing tests.

Fix:

1. Freeze E2E test creation temporarily
2. Identify the business logic under each E2E test and push it down to unit tests
3. Replace E2E tests that verify integration logic with API-level integration tests
4. Keep only the E2E tests that verify critical user journeys end-to-end

The Hourglass

      /  E2E Tests  \          Many
     /───────────────\
          |     |              Few integration tests
     \───────────────/
      \ Unit Tests  /          Many
       \───────────/

Symptoms:

• Unit tests pass and E2E tests fail -- but nobody knows why because the integration layer is untested
• Bugs cluster at service boundaries (API contracts, database queries, message formats)
• Mock-heavy unit tests give false confidence (tests pass but the real integration is broken)

Root cause: The team tests the extremes (isolated units and full journeys) but skips the middle (how components actually interact).

Fix: Add integration tests at every service boundary. Test the actual API calls, database queries, and message formats, not mocked versions.