When I first got into TDD, I thought I had it figured out.
I was reading Kent Beck, Martin Fowler… all of it just made sense.
I was really into clean code and unit tests.
I knew about e2e testing, but I saw it as QA’s job, not mine. Those tests were really badly written and constantly breaking. And to be honest, I saw it as boring and something that developers shouldn’t be doing.
I saw the whole CI/CD pipeline as a separate thing done by a DevOps engineer — not me.
Still, no matter how many unit tests were written, management kept on complaining:
“Why are there still so many bugs?”
“Why is everything taking so long?”
“I thought the last release fixed this!”
“Customers are frustrated — something has to change!”
⚡Want to skip the pain and go straight to the solution?
Every Release Is a Nightmare doesn’t have to be your reality.
Limited spots. Register now with the early bird discount - 100 EUR off with code EARLYBIRD100
A Story That Stuck With Me
Later, I stumbled across something Dave Farley shared. The teams were practicing TDD… they were lots of unit tests, all green — but the system was failing in QA environment, for possibly weeks. QA engineers constantly had to play catch-up with their e2e tests.
And that’s what got Dave Farley to develop acceptance tests.
I realized I had to see the bigger picture.
That meant looking at the whole continuous delivery pipeline and understanding how all the pieces fit together.
In the commit stage, we’re doing TDD and writing unit tests (and component tests)— making sure each component behaves the way we expect.
But further down the pipeline, there’s the acceptance stage, where ATDD comes in — checking that all those pieces actually work together as a system.
⚡TDD & ATDD in Microservice Architecture
ATDD: Seeing the System as a Whole
If you zoom out and look at the system… it starts with a user story.
And that story comes with acceptance criteria — the conditions that tell you: did we actually deliver what the user needs?
Instead of just reading those criteria… we can turn each one into an acceptance test. It’s basically like 1:1 mapping.
And these tests are very different from unit tests.