What is the testing diamond vs testing pyramid?

Beyond the classic pyramid, teams have proposed variations: Testing Diamond (or Honeycomb): wide in the middle (service/integration tests), narrow at top (E2E) and bottom (unit). Popularized by Spotify. The philosophy: integration tests (testing a service with all its real internal components) provide the best ROI — they test realistic scenarios without the brittleness of full E2E tests, and more confidence than unit tests with mocks. Unit tests are used only for complex algorithmic logic. Testing Honeycomb (Spotify): same as diamond but explicitly names the middle layer "service integration tests." Testing Trophy (Kent C. Dodds): similar — wide integration middle, with static analysis at the very base. When diamond/honeycomb makes sense: API-centric services (backends, microservices) where integration tests with real databases (Testcontainers) are fast, reliable, and test the full stack; frontend code where integration tests (React Testing Library) test component + hooks + rendering together. Pyramid still makes sense: complex domain logic with many rule combinations — unit tests scale better.