The Test Pyramid guides how to distribute tests: many fast, cheap UNIT tests at the base, fewer INTEGRATION/API tests in the middle, and few slow, brittle UI/E2E tests at the top. Framework design should honor this balance.
UI tests are valuable but slow and flaky, so you want FEW of them covering critical journeys, while pushing most coverage down to faster API and unit tests. An 'ice-cream cone' (mostly UI tests) is an anti-pattern — slow, brittle suites. A good framework makes it easy to test at the right level: API tests (REST Assured) for business logic and setup, UI tests only for what genuinely needs the browser, and uses API calls for UI-test SETUP (seed data fast, then verify one thing in the UI). Balancing the pyramid is a core design/strategy question.
Instead of 500 UI tests, the team keeps ~50 UI tests for critical flows and moves the rest to fast REST Assured API tests, and uses API seeding to set up each UI test — cutting runtime from hours to minutes.
A suite of 400 UI tests takes 4 hours and is flaky. How does the test pyramid guide a redesign?