👋 Hello, this is Valentina with the free edition of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code.
It’s tempting to write code fast and plan to clean it up later.
Skip the naming.
Duplicate a bit of logic.
Add “just one more if”.
Messy Code Is a Tax
Every change on top of messy code costs more:
Features take longer because you can’t trust what’s already there. You read more than you write, trying to figure out what the code actually does.
Bugs hide in unclear abstractions and duplicated logic. You fix something in one place and miss the copy-pasted version three files over.
Refactoring is painful because dependencies are tangled. You pull one thread and everything unravels.
So you slow down. Every change gets harder. Every decision gets riskier. Every task takes longer than it should.
And the worst part? You know you should fix it, but now you can’t justify the time — because there’s a backlog of features waiting.
This is how codebases rot. Not from one bad decision, but from hundreds of small ones that compound.
No matter how slow you are writing clean code, you will always be slower if you make a mess. — Uncle Bob
Clean code may feel slower at first. But every line you write on top of it is faster, safer, and less stressful.
The hard truth: Messy code always costs more time than taking the time to do it right.
But How Do You Keep Code Clean — and Keep It Working?
Say you’ve written clean, well-structured code. You refactor a service, rename some methods, extract a class. The code reads well. You’re confident it’s correct.
But is it?
How do you know that the order flow still works end to end? That the payment integration didn’t break? That a customer can still check out?
You don’t — unless you have tests that verify behavior, not implementation.
Clean Code Needs a Safety Net
Unit tests are fast. They give you quick feedback and make refactoring feel safe.
But even the best unit tests have a blind spot.
They verify pieces in isolation. They mock the database, stub the API, skip the serialization. So when everything passes, you know your unit logic works — but you don’t know if the system logic works.
The gaps live at the boundaries: the database query that returns data in a different shape than you assumed. The HTTP layer that silently drops a field. The integration that worked in isolation but breaks when it meets real I/O.
Unit tests can’t catch these problems — not because they’re poorly written, but because that’s not what they’re designed to do.
Acceptance tests fill that gap. They exercise the system end-to-end, through the same boundaries your users hit:
A unit test says: “This function calculates the discount correctly.”
An acceptance test says: “When a customer applies a coupon at checkout, the total price is reduced and the order goes through.”
They’re slower than unit tests. You won’t run them on every keystroke. But they answer the question that unit tests can’t:
Does this actually work for the user?
Clean Code Without Acceptance Tests Is a Risk
Clean code keeps you moving fast. Unit tests ensure your refactoring doesn’t break the unit's logic. So why do you need anything else?
Because unit tests verify your code works in isolation. Acceptance tests verify your system works in reality.
You can have clean code, a full suite of passing unit tests, and still deploy a broken checkout flow — because the bug lives at a boundary that no unit test touches.
Clean code lets you move fast.
Unit tests make sure the pieces work.
Acceptance tests make sure the system works.
One without the other will eventually slow you down.
You need all three.
Where do you start?
If you’re working in a greenfield project, you can build all three from day one.
But what about legacy code — where there are no tests, and the code is too messy to unit test?
You don’t start with unit tests. You can’t — the code isn’t structured for them yet.
You start with acceptance tests.
They don’t need clean code. They don’t need dependency injection or isolated modules. They test the system from the outside, through the same entry points your users hit. That means you can add them to any codebase, no matter how messy.
Once acceptance tests are in place, you have a safety net. Now you can refactor toward clean code and add unit tests — without breaking what already works.
Ready to put this into practice?
I’m running a hands-on Acceptance Testing Workshop on May 27–28 (4 hours).
Limited spots. Register now with the early bird discount - 100 EUR off with code EARLYBIRD100
You can write messy code fast. You just can’t move fast after that.