What I learned about the testing pyramid

Kacper Góra — Tue, 02 Jun 2026 08:19:12 +0000

I used to write tests mostly because: "you should write tests.", with poor mental model 'because the best practices say so', with truly not understanding potential benefits

I understood the rule, but not the reason behind it.

Then I did a refactor — and for the first time, tests actually saved me.

Then i realized that, I was wrong, or at least not exactly right but I was missing the crucial point.
The real value showed up when I started refactoring parts of my side project.
Changing a service, restructuring a module, updating dependencies — without tests, the only way to verify nothing broke was manual testing.
Click through the app, hope for the best, deploy and pray. A lot of pain.

With tests in place, the feedback was immediate. That's when the testing pyramid clicked for me.

Unit tests at the base — fast, cheap, and isolated. They tell you what broke and why. They also can serve as simple documentation for the business logic. The fundamental part of tests.

Integration tests in the middle — they verify your modules work together.

E2E at the top — slow and expensive, but they confirm the whole flow works. Best for critical paths - auth flow / payment flow etc.
The pyramid isn't about writing more tests. It's about writing the right tests with good balance.

In practice, tests rarely feel like a priority. They take time, they slow down early development, and when you're moving fast — they're easy to skip.
But the cost shows up later. Not during the initial build, but during every change that comes after.

Those changes usually come from a better understanding of the business domain, evolving client requirements, or new product ideas. The challenge is that every change must coexist with what already exists. Users still depend on the current system while expecting new features and improvements.

E2E gives you confidence. Unit tests give you precision. You need both, but in the right proportions.
My takeaway: tests don't slow you down during development. They speed you up during refactoring — which is most of the job.

systemdesign #softwaredevelopment #nestjs #learninpublic

What DDIA taught me about reliability

Kacper Góra — Sun, 31 May 2026 09:58:01 +0000

I used to think a reliable system was simply one that doesn't crash.

The book challenges that from the first pages.

Failures are expected. Databases go down. Networks fail. Third-party APIs stop responding.
What matters is not whether failures happen — it's how the system behaves when they do.

This hit me immediately when I thought about a service instance I've been working with.

If it suddenly became unavailable — what would happen?
Would the app degrade gracefully, serving cached data or a fallback?
Or would the entire request chain fail?

The honest answer: I hadn't thought about it carefully enough.

Key takeaway from chapter 1:

Reliability is not about preventing every failure.
It's about designing systems that continue operating despite them.

Hardware faults, software errors, human mistakes — they're not edge cases.
They're the default state you design around.

systemdesign #softwaredevelopment #ddia #learninpublic

DEV Community: Kacper Góra

What I learned about the testing pyramid

systemdesign #softwaredevelopment #nestjs #learninpublic

What DDIA taught me about reliability

systemdesign #softwaredevelopment #ddia #learninpublic