Is the Test Pyramid Still Valid in Agile Development?

You've probably seen the test pyramid if you've worked in software testing for more than five minutes. It's the classic advice:

• Lots of unit tests

• Some integration tests

• A few UI tests
  

But here's the question: Is the test pyramid still valid in modern agile teams?

Well, let's take a deeper delve, shall we?

Where the Test Pyramid Still Works

The pyramid was built on solid ground. It reminds us to:

• Push logic down to the smallest testable unit

• Avoid an overreliance on slow, brittle UI tests

• Think about test value, not just test volume

  
  

That's still good advice. The pyramid's warning lights are flashing if your test suite is 90% click-through UI tests that take 40 or more minutes to run!

But Agile Changed the Context

Agile teams deliver fast. Really fast! And that changes how we test:

• Features are built incrementally

• APIs and UIs evolve together

• Developers and testers collaborate more closely

• Tests are run constantly in CI/CD pipelines

This means we need to rethink our approach to coverage. Ideally, your test suite would run after each deployment, giving immediate feedback (Yes, yes. I know. But we try, right?)

How popular will your test suite be if the deployment pipeline is tied up for 2 hours? How about when a UI test that hasn't been updated with a new drop-down value fails the whole thing and triggers a rollback?

How to not make friends...

Think Layers, Not Shapes

The pyramid is a helpful metaphor, but think about agile testing as more of a layered strategy than a fixed structure. The clue is in the name—agile!

Here's a more adaptable way to think about it:

• Unit tests → Validate logic quickly and cheaply

• Integration tests → Catch real-world behaviour across services

• API tests → Confirm data contracts and edge cases

• UI tests → Validate what the user experiences
  

Yes, every story needs a test. But does that tech debt story

There isn't a "one size fits all" silver bullet solution to this. It all depends on:

• Your app's architecture

• The risk of failure

• Time to run

Does your app's processing occur in the deep, dark underbelly layers, like database queries? Or do you have lots of UI-level data slicing and filtering? This will impact where to focus your coverage and, as a result, what triggers your tests to run.

Wrapping Up

So, is the test pyramid still valid?

Yes… But don't follow it unthinkingly.

Use it as a guiding principle, not a strict formula: balance speed, coverage, and confidence.

Most importantly, test what matters most to your users and business!

Do you need help reviewing your current test strategy or balancing your layers? We specialise in these areas, so if you do, get in touch here:

🔗 ps-testing.co.uk