Is the Test Pyramid dead yet? No. It’s alive and kicking. I’m still talking about it (in fact in my next seminar at DevGeekWeek ’23, I’m going to mention it). Most people are aware, but there’s a lot of misunderstanding about the test pyramid.
The number of tests in each level correlate to cost – cost of writing, debugging and fixing. Unit tests are quicker, cheaper and easy to debug. End-to-end – less so. The upside-down pyramid is usually discussed as an anti-pattern. A lot of effort goes into E2E, less into unit tests. I mean, what’s wrong with these people, don’t they want to be part of a pyramid scheme?
Why is that, really? Maybe the test pyramid is not what the cool kids say it does?
I think there are a couple of reasons people go to the upside-down. It’s perception of cost of developers (they should be writing code, not tests), and the pushback (they don’t see that as part of their job), and role of testers (they should focus on finding bugs in the systems).
But it comes down to the purpose of tests: Confidence. We don’t perceive passing unit tests as valuable enough to build confidence. We value passing end-to-end tests to build confidence in the product. We value value over cost. (We need this as the corproate moto).
Does that mean we all need to build upside-down pyramids?
Hold on, I remembered something
A few years ago, I was in a panel in an agile conference. We were asked about what it takes to implement the Spotify model. When it was my turn, I asked the audience how many of them were working on a music streaming company. No hand was raised. I then asked: “Why do you think a model that fit (past tense, even then) Spotify, would fit your company?”
Back to our regular program
Why do you think the test pyramid is relevant – for you?
Maybe you write a not-so-complex CRUD application. unit tests won’t help here. No logic means easy-to-write tests, that always pass. CRUD APIs tests without the database are the same. Even some tests with the databases (depending on the queries complexity), may not raise enough confidence.
On the other hand, if you’re running complex algorithms, spanning different modules and services, better focus on them. If unit level tests work, great, if not – write longer tests.
Oh, it gets better. Did you know that if you wrote the code differently, your test needs will change? Like, if our complex algorithm sat in one place, it would be easier to test. Maybe, easier to unit test. That’s the magic of testabilty for you.
Or, if the code is crappy, unit testing is challenging (I’m using kind words), and therefore, you may search for your luck somewhere else.
Your code impacts your choice of tests.
The model (pyramid or any other shape) is not important. It may fit your situation, or not, but you don’t get points for that, either way.
Are your tests effective? Do they bring you value at the right cost? That’s the important part. Even, if it’s amoeba shaped.
Test planning is a skill. Learn about it in my “API Automation Testing Workshop“.
0 Comments