Subscribe now

Now you’ve written a test.

But does it fail?

If it doesn’t, you have no proof that your implementation makes a difference.

A test that always passes is worse than no test.

It gives you a false sense of security.
It hides bugs instead of exposing them.

That’s why the RED step matters.

You watch it fail.

That failure is evidence.

Later, when it turns GREEN, you know the code caused it — not luck, not a misconfigured test, not a false positive.

⚡Can the Test Actually Fail?

If you’ve seen it fail:

• It confirms the test is valid.

• It means that the later GREEN step actually proves your code works.

• It protects you from false positives — those sneaky tests that always pass, giving you a fake sense of correctness.

TDD makes it unavoidable.

No RED? No trust in your code.

Why Developers Skip It (And Regret It)

It’s tempting to skip RED:

• “I know this code will work, so why watch it fail?”

• “It’s faster to just implement and see GREEN.”

But skipping RED is like installing a fire alarm that never goes off — you won’t know something’s broken until it’s too late.

Watching the test fail is the cheapest, fastest bug prevention you can get.

RED Before GREEN

TDD isn’t just about writing tests.

It’s about proof.

Proof that your test matters.
Proof that your code works.
Proof that the system behaves as expected.

You can take a step further with Acceptance Test–Driven Development (ATDD).

Instead of just asking:

“Does my code work?”

ATDD asks:

“Does the system behave as the user expects?”

It’s less about writing more tests and more about making sure everyone — Devs, QA, and Product Owners — agrees on what “done” really means.

The cool part? Fewer arguments about whether something is broken, fewer regression bugs, and a lot less late-night firefighting — because expectations are clear before you write a single line of code.

🚀 Join me for: ATDD – Acceptance Testing Workshop

Join the workshop →

Limited spots. Get 100 EUR off with code EARLYBIRD100

Subscribe now

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).

Join the workshop →

Limited spots. Register now with the early bird discount - 100 EUR off with code EARLYBIRD100

Subscribe now

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.

Join the workshop →

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.

Read more

Subscribe now

Most devs start coding with only a hazy idea of what “done” really means.

• You assume requirements are clear.

• You assume you understand the edge cases.

• You assume QA will catch any gaps.

TDD forces you to confront assumptions before you touch the code.

It’s not about writing more tests.
It’s about clarity, assurance, and focus.

When you know you can test a requirement, you know exactly what success looks like.

And that changes everything — from how you design your interface to how you structure your implementation to how fast you can deliver working software.

⚡Can You Even Test the Requirement?

Before you write code, TDD forces you to ask:

Can I write a test for this requirement?

If you can’t, something’s wrong.

Maybe:

• The requirement is vague.

• There’s no concrete example.

• Nobody knows what “done” really means.

And here’s the uncomfortable truth:

If you can’t construct an example to verify the requirement…
… you’re about to implement something blind.

You might push code that looks correct.
It might even pass code reviews.
And yet… it may fail silently in production.

TDD flips the script.

The first checkpoint isn’t your implementation.
It’s the requirement itself.

No test? No implementation.

That simple rule prevents hours (or days) of wasted effort, wasted code, and wasted frustration.

⚡TDD & ATDD

TDD is amazing at keeping your code correct, but it mostly protects your implementation.

ATDD (Acceptance Test–Driven Development) takes it one step further.

Instead of just asking:

“Can I write a test that proves my code works?”

ATDD asks:

“Can I write a test that proves the system behaves as the user expects?”

It shifts the focus from “my code works” to “the system works for everyone.”

• Requirements become executable specifications.

• Developers, QA, and Product Owners are all aligned on what “done” really means.

• Regression bugs drop, because everyone agrees on the expected behavior before a single line of code is written.

Think of it this way:

• TDD protects the code.

• ATDD protects the behavior.

If you’re working on legacy systems or teams where QA keeps reporting regression bugs, ATDD can transform the process — turning vague requirements and tribal knowledge into tests that everyone trusts.

⚡Release Without the Stress

You know something is wrong with how testing is done.

This workshop is for engineers who refuse to accept that “this is just how it is.”

Date & Time: Wed Feb 25, 5-7PM (CET)
Where: Live online
Cost: €97 — (100% off for Optivem Journal paid members)

📌Spots are limited – Sign up here: Acceptance Testing (Live Training)

Reserve Your Spot

🎁 Free for Paid Members - Claim your 100% discount
Not a member yet? Upgrade now for immediate access and replays

🔒 Hello, this is Valentina with a premium issue of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code.

Subscribe now

Many years ago, I used to think every test had to touch everything — the database, other services, payment providers… you name it.

Then I realized: that’s inefficient, feedback loop is too slow. We need tests at different levels.

A user adds a product to their cart, maybe ten times while browsing, and then finally hits checkout, then later cancels their order.

That’s two very different use cases: AddItemToCart and PlaceOrder. And each requires different tests.

The problem: Use Cases and the External World

Most real-world use cases depend on something external:

• Databases

• Message brokers

• External API services

For example, the PlaceOrder use case involves the DB (we need to save orders), it involves message brokers (we publish an event, so that the reporting service can register the newly placed order), and it involves external API services (we need to use PayPal for processing payment for the placed order).

The problem with testing use cases in this way, involving the external world are the following:

• The test is too slow due to the I/O

• We might not be able to test various logic scenarios

• The test might not be able to run if the external system is not available

The solution: Isolation from the External World

In order to be able to test our use case in isolation from the external world:

• User-side api: We test the use case via its driving (incoming) port, so that we bypass UI / REST API

• Server-side api: We “mock out” the driven (outgoing) ports, so that we’re excluding DB, external APIs, etc. In this way, the use case depends on interfaces of the external world, and doesn’t know (or care) about concrete implementations

This keeps your core logic isolated and maintainable.

Server-side API: Enter Test Doubles

When we write unit tests, those server-side ports are replaced with in-memory test doubles:

• Repositories Test Doubles (e.g. Order Repository Test Double)

• Gateway Test Doubles (e.g. Notification Test Double, Payment Test Double)

There are different types of Test Doubles: Dummies, Fakes, Stubs, Spies, Mocks (see Fowler’s Test Double article)

The test doubles:

• Live entirely in memory

• Run ultra fast

• Behave predictably

Basically, they let your tests focus on business logic, not “what the database or external API does today.”

Note: The above image is for a microservice, but a similar image can be applied to the frontend. Also, in case of monolithic architecture, similar image can be applied to the monolith.

AddItemToCart vs PlaceOrder (Real-life Example)

Read more

🔒 Hello, this is Valentina with a premium issue of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code.

Subscribe now

If you’ve ever sat in a Friday meeting, you’ve probably heard:

“We need to follow SOLID!”
or
“TDD will guide our architecture!”

But here’s the uncomfortable truth:

Most developers treat SOLID like a rulebook and TDD like a silver bullet.
And neither works that way.

The real question is: which one actually drives design?

SOLID: The Smell Detector

SOLID provides a set of principles for maintainable code. When you use SOLID principles to review code, you can notice design smells:

• Single Responsibility Principle: helps you notice volatile classes

• Open/Closed Principle: helps you see where abstraction is needed

• Liskov, ISP, DIP: point out awkward dependencies

TDD: The Design Engine

TDD (Test-Driven Development) helps us design in the following way:

• Red → write a failing test → this is forcing us to design the interface that exposes some behavior

• Green → write the minimum code to pass → typically there is not much effort here regarding design, quick-and-dirty is fine

• Refactor → we refactor code —> clean design emerges

Therefore, TDD leads to:

• Well-designed interfaces (in the RED step)

• Well-designed implementation (in the GREEN step)

A Real-World Example: TDD First, SOLID After

Read more

🔒Hello, this is Valentina with a premium issue of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code. This article is part of the TDD in Legacy Code series.

Subscribe now

Frontend Component Tests provide fast feedback

We’ve seen in the previous article, Frontend Component Tests in Legacy Code, that Frontend Component Tests can provide us with fast feedback. The Frontend Team can test Frontend in isolation, by stubbing out the Backend.

But they can be a maintenance nightmare!

In Frontend Component Tests in Legacy Code, we illustrated the “simplest“ Frontend Component Tests. But unfortunately, they are unmaintainable.

The simplest way to write a Frontend Component Test is to locate UI elements via Text, Role, ID, etc., then trigger some actions on those UI elements. For example: (pseudocode)

  const skuInput = screen.getByLabelText('SKU');
  fireEvent.change(skuInput, { target: { value: 'APPLE1001' } });

The problem with these kinds of tests, is that if there is UX/UI Redesign, or some UI refactoring, that many such tests may break, so we have to waste time fixing tests.

How to write maintainable Frontend Component Tests?

In this article, I’ll show you how to introduce layers of abstraction, i.e. Component Test Architecture, so that you spend much less time writing & maintaining these tests.

Here are the steps to introduce Maintainable Frontend Component Tests in Legacy Code. You’ll get tasks to implement in your GitHub Sandbox Project. ⬇️⬇️⬇️

Read more

🔒 Hello, this is Valentina with a premium issue of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code.

Subscribe now

When practicing TDD in Hexagonal Architecture, unit tests should target use cases - not internal classes, not frameworks, and not implementation details.

In other words: our tests interact with the business logic as an external observer.

Unit Tests Target the User-Side API

Unit tests talk only to the user-side API, which represents the component’s use cases:

• AddItemtoCart

• RemoveItemFromCart

• ViewCartContents

• CalculateCartTotal

• FilterCartItems

• GetProductPrice

The tests know nothing about:

• Internal classes
  (e.g. Cart, CartItem, PricingCalculator, InventoryChecker)

• Frameworks
  (e.g. Spring, Hibernate, Express, NestJS)

• Persistence
  (e.g. SQL queries, ORM mappings, database schemas)

• Network calls
  (e.g. HTTP requests to inventory or payment services)

• Technical plumbing
  (e.g. transactions, caching, logging, retries)

This is great because it means that we can do refactoring in a safe way.

As long as the use case behaves the same from the outside, we can:

• Rename classes
  (e.g. CartService → ShoppingCart)

• Split logic
  (e.g. extracting pricing rules into a separate domain object)

• Merge logic
  (e.g. consolidating duplicate validation code)

• Move code around
  (e.g. shifting logic from a service into a domain entity)

• Change implementations entirely
  (e.g. in-memory storage → database, sync calls → async events)

…and our tests remain green ✅

Use Case First, Implementation Later

In TDD, we write a unit test for a specific use case (the test describes behavior in business terms). Only then do we implement the use case (classes and code emerge naturally).

We focus purely on:

• Inputs
  (e.g. customerId, sku, quantity, passed to AddItemToCart())

• Outputs
  (e.g. cart contains the correct items and quantities, total price is calculated correctly)

• Observable side effects
  (e.g. an exception is thrown when adding an unavailable product, the cart is persisted via the repository interface)

This:

• Prevents premature design
  (e.g. you don’t design CartItem or PricingCalculator before knowing what behavior is required)

• Avoids over-engineering
  (e.g. you don’t implement caching, events, or complex inventory logic before it’s needed)

• Forces the design to stay aligned with real usage
  (e.g. the system only supports adding/removing items, calculating totals, and viewing the cart exactly as users would do, rather than unnecessary internal implementation details)

Big Picture

The test enters through the same door as a client of the user-side API.

Since we want the test to span the hexagon only, we then have to “mock out“ the server-side API, e.g. using fake adapters.

Real-Life Example: Ordering System

For an e-commerce system, suppose we have a frontend and a backend. We model the backend using Hexagonal Architecture. Let’s see what the user-side API looks like on the backend:

Read more

🔒 Hello, this is Valentina with a premium issue of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code.

Subscribe now

🚫 High coupling – Tests coupled to Structure ➔ Fragile Tests

Do NOT write tests as specifications of your implementation.

When your tests know too much about the system’s internals (specific classes, methods, or dependencies), the tests become tightly coupled to the implementation, i.e. the internal structure.

If you change an implementation class, the test will break. This kind of testing leads to fragile tests.

🔍 Example symptoms:

• Tests instantiate internal classes directly

• Tests depend on method names or call chains

• Small refactorings cause test failures even when behavior hasn’t changed

💥 The result:

• Refactoring becomes risky and slow

• Developers fear touching the code

• Tests no longer describe behavior — they describe implementation details

✅ Low Coupling – Tests coupled to Behavior ➔ Stable Tests

DO write tests as requirements of the system.

Tests should communicate with the module’s public API and test the module’s external behavior. A module consists of a group of classes, where one class acts as the public class (exposes the module’s public API, it’s the entry point to the module) and the other classes are internal classes (they are implementation details of the module).

When our tests don’t know about implementation (treating it as a black box), we can change the internal implementation and we’re not going to break the tests.

We can do as much refactoring as we want, and the tests will not break.

✅ Characteristics:

• Tests verify the module’s behavior, not its internal implementation.

• Internal classes can change freely without breaking tests.

• You can refactor safely and move fast.

💡 Example:

• Your tests call OrderService.placeOrder() instead of directly testing the underlying repository, entity, or validation class.

• If you refactor OrderService or your validation class, the tests still pass — because behavior hasn’t changed.

Real-life Example: Ordering System

Read more

🔒 Hello, this is Valentina with a premium issue of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code.

Subscribe now

Testing the Frontend in isolation

Previously, in Frontend Component Tests in Legacy Code, we saw that the Frontend team can get feedback whether the Frontend works in isolation, by stubbing out the Backend. This means they don’t have to wait for the Backend team.

Testing the Backend in isolation

Similarly, the Backend team can get feedback whether the Backend works in isolation, by stubbing out External Systems. Backend Component Tests are independent of Frontend Component Tests, hence can be written in parallel.

Here are the steps to introduce Backend Component Tests in Legacy Code. You’ll get tasks to implement in your GitHub Sandbox Project. ⬇️⬇️⬇️

Read more

🔒 Hello, this is Valentina with a premium issue of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code.

Subscribe now

You can achieve 100% code coverage having tests with zero assertions!

TDD isn’t about having useless or illogical tests just for the sake of reaching a certain metric.

The main goal of TDD is that we’re driven by specifications, and that the code we produce is testable and aligned with specifications.

High code coverage is just a byproduct of TDD, but not the goal.

100% code coverage, 0 assertions

You can literally hit every line of code with your tests — and still have no validation of behavior. This is called a “zero assertion test“.

Read more

🔒 Hello, this is Valentina with a premium issue of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code.

Subscribe now

I thought that: class = unit of isolation

When I first started practicing TDD, I thought that “unit” in Unit Test meant “class.” I’d write a test class for every production class and a test method for every method. I’d isolate the class under test by mocking everything it touched - even things that didn’t make sense to mock:

• Write a test class for each production class

• Write a test method for each production method

• Isolate the class under test by mocking out all its dependencies

Indeed, this is the same thing that Uncle Bob said many people try to do:

“Most people who are new to TDD… create a kind of one-to-one correspondence between the production code and the test code. For example, they may create a test class for every production code class. They may create test methods for every production code method.”

Of course this makes sense, at first. After all, the goal of any test suite is to test the elements of the system. Why wouldn’t you create tests that had a one-to-one correspondence with those elements? Why wouldn’t you create a test class for each class, and a set of test methods for each method? Wouldn’t that be the correct solution?

And, indeed, most of the books, articles, and demonstrations of TDD show precisely that approach. They show tests that have a strong structural correlation to the system being tested. So, of course, developers trying to adopt TDD will follow that advice.

– Uncle Bob (TDD Harms Architecture)

⚠️ But “class = unit of isolation” is problematic!

Let’s see what happens when you write a Unit Test Class for each Production Class, and when you write a Unit Test Method for each Production Method.

Let’s say you refactor your code. Recall that refactoring means changing structure, without changing observable behaviors:

“Refactoring (noun): a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior”

– Martin Fowler (Definition of Refactoring)

Examples of refactoring:

• Changing the signature of a public method

• Moving a public method from one class to another

• Splitting a class into multiple classes

In these cases of refactoring, you’ll end up with broken unit tests! Why? Because the unit tests are coupled to the structure of the code! The tight coupling leads to fragile tests:

“The problem is – and I want you to think carefully about this next statement – a one-to-one correspondence implies extremely tight coupling.

Think of it! If the structure of the tests follows the structure of the production code, then the tests are inextricably coupled to the production code…

It, frankly, took me many years to realize this. If you look at the structure of FitNesse, which we began writing in 2001, you will see a strong one-to-one correspondence between the test classes and the production code classes…

And, of course, we experienced some of the problems that you would expect with such a sinister design. We had fragile tests. We had structures made rigid by the tests. We felt the pain of TDD. And, after several years, we started to understand that the cause of that pain was that we were not designing our tests to be decoupled.

– Uncle Bob (TDD Harms Architecture)

So what if the tests are fragile? Well, we end up with increased maintenance costs. Because when we are refactoring, the tests break, so we have double the effort:

• Effort of making the change in the code itself —> this is necessary

• Effort of “fixing“ the broken test —> this is a waste of time

So then we don’t want to refactor! This leads to code rot. Unmaintainable code makes future code changes even more expensive!

To summarize, the belief that “class = unit of isolation“ leads to higher maintenance costs and slower delivery.

The alternative: “behavior = unit of isolation“

In the above, we’ve seen the problem of structural coupling, where tests are coupled to the structure of code; for every class, there’s one test. This leads to fragile tests, causing higher maintenance costs (and slower delivery).

The alternative is behavioral coupling, where tests are coupled to behavior of the code; for every behavior, there’s one test. This leads to robust tests, causing reduced maintenance costs (and faster delivery).

This is exactly what Kent Beck remarked:

“Tests should be coupled to the behavior of code and decoupled from the structure of code.”

– Kent Beck (Twitter)

Suppose that we have a class BankAccount, that exposes the withdraw() method. Internally, it calls classes BalanceCalculator and FeeCalculator. In that case, we could say that BankAccount is a “public” class, whereas BalanceCalculator and FeeCalculator are “internal“ classes.

In cases of structural coupling, we write 1 Test Class for 1 Production Class:

• BankAccountTest class for BankAccount class

• BalanceCalculatorTest class for BalanceCalculator class

• FeeCalculatorTest class for FeeCalculator class

In case of behavioral coupling, we write a Test Class only for the “Public“ Production Class (that exposed behavior) and we do NOT write any Test Classes for the “Internal“ Production Classes (because they are just a structural implementation detail). So we just have:

• BankAccountTest class for BankAccount class (because that’s the “public class“)

Please note, in both cases, the code coverage will be the same.

In the case of behavioral coupling, if “internal“ classes are refactored, it will not cause breakage to the tests, because tests are coupled only to the interface of the “public“ class. So in this way, we reduce maintenance costs.

This means we are testing BankAccount, which traverses BalanceCalculator and FeeCalculator. We do NOT mock BalanceCalculator and FeeCalculator.

The only thing we’ll mock out are external dependencies that involve I/O (e.g. file system, database, network, etc.) or non-determinism (e.g. system clock).

Real-life Example: Ordering System

Read more

🔒Hello, this is Valentina with a premium issue of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code. This article is part of the TDD in Legacy Code series.

Subscribe now

You’re stuck in maintaining a Legacy Product. There’s no tests, you’re relying on the slow Manual QA. Most of your team’s sprint time is spent in fixing regression bugs and reworking features. Business is angry why nothing is delivered.

Everyone accepts this as “it’s the way things are, there’s nothing we can do about it“.

The “silver bullet” fallacies

So your team got together, and they all acknowledge these problems:

• Delivery is too slow (and it keeps getting slower)

• Too many regression bugs (and the bug count rises over time)

But then, when it comes to how to solve the problem, this is where it starts getting really messy. Everyone has a different opinion of what’s the root cause, and what needs to be done first.

Some people see the problem with code and architecture:

“AI is the solution to everything. If only we bought the next latest-and-greatest AI tool to write 90% of our code, then we’d be shipping fast.“

“We have an old tech stack. If only we moved to the next shiny programming language and the latest framework, then our problems would be solved.“

“The problem is that we have a monolith. If only we moved to microservices, then all our problems would be solved.”

“Our code is messy. We should focus on SonarQube reports. If only we had clean code, then all our problems would be solved.“

Some people see that the problem is with our process of working:

“The problem is our User Story tickets. If only the PO was writing more detailed tickets, then it would solve our problems. The PO is the root cause of all problems.“

“The problem is that we have too many Scrum meetings. If we eliminated those meetings, then developers would have more time to do real work.”

“The problem is JIRA, we have to spend too much time on the tickets. If only we moved to a simpler ticketing system, we’d have less wasted time.“

“The problem is we have a siloed organization and we’re not communicating well. If only we solved the people problem, then we’d have better delivery.”

“Our PR review process is not good enough. Let’s write a procedure on how to do it better. We also need to have multiple reviewers.“

“If only we had well-documented coding standards, then developers would do more quality work.“

Some people see the problem as we’re understaffed:

“We don’t have enough developers. If we hired more developers, then things would speed up.“

“We don’t have enough QA Engineers. If we hired more QA Engineers, then it would reduce testing time.“

Some people see the problem as being that we don’t have tests:

“Let’s automate E2E Tests. We could buy an AI tool to do that. Then we could get rid of Manual QA.”

“If we wrote Unit Tests and had 80% code coverage, then we wouldn’t have these bugs. It’s important to catch bugs early.“

Some give up, and say the only solution is to start from scratch:

“Everything is horrible. We should just fire everyone, hire 10X developers and rewrite everything from scratch.“

Do NOT start with Architecture Redesign.

You try to redesign Architecture, for example, by making your Monolith modular. Or you try to switch from the Monolith to Microservices. Or you want to redesign your Microservices to escape the Distributed Monolith. Or you want to restructure your database to support a modular system. Because you heard “modular“ means good.

❌ If you try Architecture Redesign, BUT you do NOT have Acceptance Tests (instead you’re relying on Manual QA), then you’re going to spend months fixing regression bugs caused by your “better“ architecture (and your architecture redesign branch redesign won’t ever be ready for production). You’ll end up with cleaner architecture, but it doesn’t work correctly, and isn’t deployed to production. This is negative ROI.

✅ The right way: Stay with your Big Ball of Mud (for now).

Do NOT start with Clean Code & Unit Tests.

You’ve probably heard Uncle Bob promoting Clean Code & Refactoring everywhere. SonarQube is reporting lots of code smells, so you have to fix them, right?

❌ If you try to refactor towards Clean Code, without Unit Tests, then you’ll cause regression bugs. So then it means you have to introduce Unit Tests first. But since the existing codebase is a Big Ball of Mud (everything is tangled up, business logic is coupled to I/O), then it’s not Unit Testable, so then you have to break dependencies to introduce Unit Tests. As you break dependencies (for the purpose of ensuring Unit Testability), BUT you do NOT have Acceptance Tests, then you’ll introduce lots of Regression Bugs (and your “big refactoring“ branches won’t ever be ready for production). You’ll end with cleaner code, that doesn’t work correctly, and isn’t deployed to production. This is negative ROI.

✅ The right way: Stay with your Messy Code (for now).

So what should we do first? ATDD.

It took me a decade to realize that the solution is to firstly introduce this:

1. Pipeline

2. Acceptance Testing

3. ATDD

When you have that foundation, then you’re ready for any other improvements. You’ll then be able to safely upgrade your Tech Stack, redesign your Architecture, introduce Unit Tests & clean up your Code.

How to introduce ATDD in 3 months?

If you’re a Senior Software Engineer or Engineering Leader, who has a strong level of self-initiative, and you want to introduce ATDD in your Legacy Project with guidance rather than trial-and-error, then I can help you:

Apply for the ATDD Accelerator Program

Now I’m going to share with you my step-by-step for implementing ATDD in Legacy Code in 3 months, without disrupting your feature delivery:

Read more

🔒Hello, this is Valentina with a premium issue of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code. This article is part of the TDD in Legacy Code series.

Subscribe now

ATDD provides business-facing feedback.

Through our journey up to now in TDD in Legacy Code series, we’ve introduced ATDD. We received major benefits from ATDD:

• We reached alignment between PO, Software Engineers & QA Engineers, so that they have a shared understanding of requirements before Software Engineers start coding

• Acceptance Tests provide us with an objective “Definition of Done“ for User Stories & Bug Tickets, and provide us with a real measure of progress

• Software Engineers receive relatively fast feedback whether they satisfied Acceptance Criteria or whether they introduced Regression Bugs, they wait for the Pipeline’s Acceptance Stage (1hr) rather than waiting for Manual QA Engineers (days/weeks)

• QA Engineers are able to bring much higher value to the team, (1) by contributing to team discussions to ensure good scenario coverage, as reflected in writing testable acceptance criteria, and (2) by being able to focus more on Exploratory Testing, Usability Testing (instead of repetitive Regression Testing)

All the above, combined, means that we are able to deliver software safely & quickly.

But the ATDD feedback loop is too long.

ATDD is excellent in providing us with business-facing feedback (did we satisfy requirements, or did we introduce regression bugs). However, we face the following issues due to the slow feedback loop:

1. It takes a long time to get feedback for a new Acceptance Test. It may take several hours/days for all teams to finish their work, associated with making some Acceptance Test pass, e.g., the Frontend Team needed to make changes, and the Backend Team needed to make their changes. We have to wait for everyone to finish, and then we’re able to see the results of the Acceptance Test. This is a slow feedback loop (we had to wait hours/days).

2. If the Acceptance Test fails, we have no idea which team is at fault - is the problem with Frontend, or with the Backend? Or perhaps is there a problem of miscommunication between them, that their API expectations aren’t matching? So we have to do time-consuming troubleshooting, involving multiple teams.

3. When we fix regression bugs (because some Acceptance Tests failed), we have to wait for 1hr for the Acceptance Stage to finish, so that we can be sure that our fix is correct and that we didn’t break anything. Similarly, when we do some refactoring, we have to we have to wait for 1hr for the Acceptance Stage to finish, so that we can be sure that our refactoring hasn’t broken anything. Suppose some Acceptance Test(s) fail. We don’t know whether our commit caused the failure or some other interim commit from another team member caused the failure, so we may need to manually review/debug multiple commits to discover which commit(s) caused Acceptance Tests to fail.

That’s why we need CTDD.

How to overcome the problems of ATDD?

We need an additional inner loop - Component Test Driven Development (CTDD). This means that each team internally would be able to specify (RED), implement & verify (GREEN), and refactor (REFACTOR) their component, independently of other components. The benefits are:

1. Our team doesn’t have to wait several hours/days for all other teams to complete their work for an Acceptance Test, but rather we get feedback in minutes whether our Component Test(s) associated with that Acceptance Test are passing, so we have assurance that our work is completed.

2. Our team doesn’t have to wait for a failing Acceptance Test to discover that we’ve introduced a bug. Instead, we’d most likely discover it through the Component Test. We can do troubleshooting within their team, no need to involve other teams.

3. When we fix a regression bug caused by our Component, or when we do refactoring, we can get fast feedback (minutes) whether or not the Component works correctly.

We need Component Tests to practice CTDD.

A key skill in practicing CTDD is the ability to write Component Tests. That is why we first need to write some Component Tests last to gain practice, before we move on to CTDD.

In this article, we’ll show how to write Component Tests. Firstly, we’ll show Frontend Component Tests, and later we’ll also show Backend Component Tests.

Here are the steps to introduce Frontend Component Tests in Legacy Code. You’ll get tasks to implement in your GitHub Sandbox Project. ⬇️⬇️⬇️

Read more

🔒Hello, this is Valentina with a premium issue of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code. This article is part of the TDD in Legacy Code series.

Subscribe now

Legacy Code might not be Component Testable

In Acceptance Testable Architecture in Legacy Code, we covered the problem where a System is not Acceptance Testable, whereby it’s statically coupled to External Systems, which included the following cases:

• Hard-coded connections to External HTTP APIs

• Static calls to the System Clock and other non-deterministic sources

• Static calls to complex external libraries

Aside from the problem of static coupling between our System and External Systems, Legacy Code also often has the problem of static coupling within our System, between the Components themselves:

• Hard-coded connections from Frontend to Backend

• Hard-coded connections between Microservices

We can’t introduce Component Tests

To write Component Tests, we need to have Component Dependency Stubs. For example: (1) to write Component Tests for the Frontend, we need to be able to stub out the Backend, (2) to write Component Tests for Microservice #1, and assuming Microservice #1 depends on Microservice #2 and Microservice #3, we then need to stub out those dependent microservices.

We need Component Dependency Stubs because they enable us to test our Component in isolation.

At runtime, to switch between Real Component Dependencies and Component Dependency Stubs, we need Component Dependency Configurability.

So we need to ensure Component Testable Architecture

That’s why we need to make some changes to our source code to ensure Component Dependency Configurability.

But how do these changes… without risking the whole system?

Here are the steps for achieving Component Testable Architecture in Legacy Code. You’ll get tasks to implement in your GitHub Sandbox Project. ⬇️⬇️⬇️

Read more

👋 Hello, this is Valentina with the free edition of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code.

Subscribe now

Don’t write broad integration tests to compensate for everything that unit tests can't do.

Broad integration tests are slow & fragile. They have similar limitations as E2E Tests, because both traverse across dependencies.

Unfortunately, I’ve seen many teams write broad integration tests!

Instead of writing broad integration tests, you need tests at different levels:

Narrow Integration Tests

Narrow Integration Tests are used to verify infrastructure logic (Driven Adapters). For example, the Order Microservice may have these Narrow Integration Tests:

• Narrow Integration Test for the Order Repository - to verify database integration (e.g. using ORM, SQL, NoSQL, etc.), e.g. when we add entities, can we retrieve them (note that the test connects to a real database via Testcontainers)

• Narrow Integration Test for the Event Published - to verify messaging queue integration (e.g. RabbitMQ, Kafka), that we are correctly mapping our events to the data structures required by the messaging brokers (note that the test connects to a real messaging queue via Testcontainers)

• Narrow Integration Test for the Product Gateway - to verify integration with another microservice, e.g. with the Product Microservice - that we are correctly mapping our domain to the requests needed by Product Microservice, and whether we’re correctly interpreting the responses from the Product Microservice (note that the test connects to a stubbed version of the Product Microservice, not the real thing)

• Narrow Integration Test for the Payment Gateway - to verify integration with an External System, e.g. PayPal - that we are correctly mapping our domain to the requests needed by PayPal, and whether we’re correctly interpreting the responses from the PayPal (note that the test connects to a stubbed version of the PayPal, not the real thing)

Narrow Integration Tests are also used to verify Presentation Logic (Driving Adapters). For example, suppose that Order Microservice exposes a REST API - then, we verify that we can correctly translate HTTP requests into Driving Port Requests, and that we can correctly map Driving Port Responses into HTTP Responses.

Component Tests

Component Tests are used to test each component in isolation from other Components.

For example, suppose that the Order Microservice depends on Product Microservice and depends on PayPal. In that case, we want to test a flow through the Order Microservice, starting at the Order Microservice REST API, including the real database (via Testcontainers) but excluding Component Dependencies (we stub out the Product Microservice) and excluding External System Dependencies (PayPal). In this way, the Order Microservice team can get feedback on whether Order Microservice itself works correctly.

Contract Tests

In the case of integrating with dependencies, since we use stubs, we want to be sure that the stubs match the real thing.

In the case of testing Order Microservice, we stub out the Product Microservice and we stub out PayPal. How do we know whether the stubs are actually valid, that their API matches the API of the real things? We use Contract Tests:

• Contract Tests for the Product Microservice & Product Microservice Stub provide assurance that the Product Microservice Stub exposes the same API that the Order Microservice relies on when communicating with the real Product Microservice Test Instance

• Contract Tests for PayPal & PayPal Stub provide assurance that the PayPal Stub exposes the same API that the Order Microservice relies on when communicating with the real PayPal Test Instance

Ultimately, we get assurance that the Real Dependency API and the Dependency Stub API match.

Acceptance Tests

Acceptance Tests provide us with assurance that business requirements are satisfied. They answer the question: Does the system work correctly (in isolation from external systems)?

For example, for an eShop System, we can test whether placing order works correctly, e.g. is the correct order price calculated. We do this by stubbing out ERP (an External System) to specify product pricing, so that we can verify, for some SKU & quantity, whether our eShop calculates the correct order total.

Summary

Testing at these levels helps you catch issues faster, keep tests maintainable, and have assurance you’re building the product right.

To learn more, read the Modern Test Pyramid.

Leave a comment

Want to apply TDD in practice?

You tried TDD, but it didn’t work. That's why I'm going to help you practice TDD step-by-step. Apply TDD on a sandbox project. Access TDD in Legacy Code.

🔒 Welcome to the premium Optivem Journal. I’ll help you apply TDD to escape the nightmare of Legacy Code. Join our paid community of 160+ senior engineers & leaders for support on your TDD journey, plus instant access to group chat and live Q&As:

Subscribe now

Previously, we covered the Modern Test Pyramid - Unit Level, where we showed why we need Unit Level Tests (Unit Tests & Narrow Integration Tests):

• Unit Tests - Provide us with extremely fast feedback on correctness of business logic, by testing business logic in isolation from I/O concerns (hence, by isolating business logic from I/O, we get feedback and order of magnitude faster). As business logic complexity increases, the number of scenarios that need to be covered also increases, which is where the benefits of Unit Tests become even more visible.

• Narrow Integration Tests - Provide us faster feedback compared to Component Tests because we eliminate the combinatorial explosion in testing I/O logic.

The question is, does it matter whether we write Unit Tests last (i.e. after code)… or write Unit Tests first (i.e. before code)?

Approach 0. Not writing Unit Level Tests

A team might be practicing Component Level TDD, without any Unit Tests.

We don’t have to write Unit Tests, or we might not even be able to write Unit Tests. We could be just writing Component Level Tests.

Case 1: Cannot write Unit Tests: Suppose that our Component architecture is not unit-testable, because there’s no separation between business logic and I/O logic. Examples are:

• We have fat REST controllers that contain everything - executing business logic, communicating with databases and external systems, and sending back a response based on some logic

• We have fat “service“ classes that do both business logic and communicate with databases and external systems

Since business logic is not isolated (it’s instead mixed with I/O concerns), it's not possible to test the business logic independently of I/O - unit tests are not feasible.

Case 2: Choose not to write Unit Tests: The Component architecture might be unit-testable (i.e. business concerns are separate from I/O concerns), but we consciously choose not to write Unit Tests. E.g. where the Component is too simple and/or where the amount of business logic complexity (roughly approximated by LOC) is not significantly higher than the amount of I/O logic complexity, or where there is much more I/O complexity. Then, we might not see the ROI of Unit Testing.

Problems solved with Component Level Tests

• Component Level Tests help teams work effectively independently & in parallel, because each team gets feedback on their Component in isolation

Problems not solved with Component Level Tests

• Developer has to wait for several minutes to get feedback (due to I/O slowness) whether they introduced a regression bug - this is especially a problem for Components with high degree of business logic complexity

The fundamental unsolved problem is that, due to the inclusion of I/O within all tests, it means the feedback loop is slow. The wait time of several minutes is too long to get feedback on business logic changes, causing developers context-switches, or preventing them from working incrementally (they may decide to batch up several changes prior to running the slow Component Tests, but then this increases the cost of debugging when some Component Test fails).

Approach 1. Writing Unit Level Tests last

At some point, in Components with high business logic complexity, the team recognizes that the waiting time for Component Tests is too slow because the Component Test suite grew a lot. Why? High business logic complexity → many scenarios → many (slow) Component Tests → feedback loop gets slower and slower.

So, the team realizes they want to adopt Unit Tests. Why? Because every Unit Test is an order of magnitude faster than a Component Test (Unit Test runs purely in-memory, Component Test includes I/O, in-memory is an order-of-magnitude faster than I/O). So we can then have hundreds/thousands of Unit Tests, and get feedback within seconds.

The team naturally starts by writing Unit Tests last. Even though they’re practicing TDD at the System Level, and at the Component Level, there is nothing to force them to practice TDD at the Unit Level. Their process might be:

1. Write a failing Acceptance Test

2. For each team, working in parallel:

   1. Writes a failing Component Test

   2. Writes some code

   3. Writes Unit Tests & Narrow Integration Tests (they pass)

   4. Verify that all the Component Tests & Contract Tests pass

3. Verify that all the Acceptance Tests pass

Problems solved with Unit Level Tests last

• The benefit is that each team gets fast feedback on whether their Business Logic works correctly, and relatively fast feedback on whether their Presentation/Infrastructure Logic works correctly

Problems not solved with Unit Level Tests last

• The Unit Tests (and Narrow Integration Tests) might not be valid, they might not be testing what we expect to be testing. This is because we’ve never seen them fail. When we see passing Unit Tests (and Narrow Integration Tests) it doesn’t mean anything - they might be always-green tests, which are useless. So, they won’t be good at detecting bugs, which means we’ll end up with a higher percentage of failing Component Level Tests, thereby wasting more time debugging.

  • We could partially try to handle this problem by using Code Coverage, to help us discover lines of code that are never executed by Unit Tests & Narrow Integration Tests. This is useful in helping us add some missing tests.

  • However, Code Coverage can’t help us know whether we’re verifying behavior - lines of code could be executed, but its output might not be asserted at all (or only partially asserted). This is where we’d need Mutation Coverage, however, the problem is that Mutation Testing is too slow, it is impractical to run it with every commit, it might be run as a nightly job (or some other interval) but that results in slow feedback. Then, we would have to spend additional time updating our Unit Tests & Narrow Integration Tests.

We end up with time wasted in late debugging & late rework (because these Unit Tests & Narrow Integration Tests are not good at detecting regression bugs, so failures are detected more at the Component Test Level). This makes development more expensive.

Read more

Subscribe now

Previously, in Modern Test Pyramid - Component Level, we showed why we need Component Level Tests (Component Tests & Contract Tests):

• Component Tests - Each team has assurance that their Component works correctly in isolation (i.e. that the Frontend works correctly in isolation, that the Backend/Microservices work correctly in isolation)

• Contract Tests - Each team has assurance that their Component can communicate with other Components & External Systems (e.g., assurance that Frontend can communicate with Backend, that Microservice 1 can communicate with Microservice 2, etc.)

The question is, does it matter if we write Component Tests last (i.e. after code)… or if write Component Tests first (i.e. before code)…

📢 On Wed 9th July 17:00 CET, I’m hosting TDD & Unit Tests - Part 4 (Live Q&A):

Register now

P.S. If you’re a Paid Member, you’ll receive a 100% discount (see Event Description for instructions on how to redeem your 100% discount).

Subscribe now

Approach 0. Not writing Component Level Tests

A team might be practicing TDD - System Level (ATDD), which aligns the whole team regarding business requirements and provides automated feedback whether they satisfied business requirements, whilst also eliminating Manual QA Regression Testing.

This team might NOT be writing Component Level Tests.

Problems solved with System Level Tests

• System Level Tests help teams align on requirements and get automated feedback on whether they satisfied the requirements.

Problems not solved with System Level Tests

• Teams cannot test their components in isolation - i.e. the Frontend Team can’t test the Frontend in isolation, the Backend Team(s) can’t test the Backend/Microservices in isolation, but must wait for everyone to finish their job to get feedback. The late discovery of bugs in components leads to more expensive rework.

• Teams have to wait for everyone to be done in order to know if they can integrate, i.e. are there any integration issues (e.g., mismatching contracts)? The late discovery of integration issues leads to more expensive rework across teams.

Thus, the fundamental unsolved problem is that, due to the slow feedback loop, teams need to do late, expensive rework. This increases the total development cost, and reduces their capacity to deliver new features, i.e. thus limiting the business value that can be delivered.

Approach 1. Writing Component Level Tests last

At some point, the teams see that System Level Tests aren’t enough, that they need Component Tests.

When teams first start writing Component Levels Tests, they naturally tend to write them last (because they were accustomed to Test Last approaches). Thus, even though they might be writing Acceptance Tests first (practicing ATDD), they might still be writing Component Tests last. Their process might be the following:

1. Write a failing Acceptance Test

2. Then each team works in parallel

   1. Frontend team writes some code, then when they finish coding, they write some Component Tests & Contract Tests

   2. Backend team(s) write some code, then when they finish coding, they write some Component Tests & Contract Tests

3. Verify that all the Acceptance Tests pass

Problems solved with Component Level Tests last

• The benefit is that each team gets feedback on whether their Component works correctly in isolation (via Component Tests) and whether their Component can integrate well with other Components & External Systems (via Contract Tests)

Problems not solved with Component Level Tests last

• The teams may face integration issues due to misunderstandings. E.g. when the teams had a meeting and agreed on their contract, they had a misunderstanding, or perhaps they both had a good understanding but made spelling errors when implementing the agreement. When they write code and then write the Contract Tests last, it provides late feedback to teams regarding their contract mismatches. This means that multiple teams may need to fix their implementation of the integration code and/or update their Contract Tests, resulting in wasted time.

• The Component Tests (and Contract Tests) might not be valid; they might not be testing what we expect to be testing. This is because we’ve never seen them fail. When we see passing Component Tests (and Contract Tests) it doesn’t mean anything; they might be always-green tests, which are useless. They won’t be good at detecting bugs, which means we’ll end up with a higher percentage of failing System Level Tests, thereby wasting more time debugging.

  • We could partially try to handle this problem by using Code Coverage, to help us discover lines of code that are never executed by Component Tests. This is useful in helping us add some missing tests.

  • However, Code Coverage can’t help us know whether we’re verifying behavior - lines of code could be executed, but its output might not be asserted at all (or only partially asserted). This is where we’d need Mutation Coverage; however, the problem is that Mutation Coverage is far too slow with Component Tests (because they include I/O), hence it’s impractical.

Thus, in both cases, it leads to wasted time in debugging and late rework, making development more expensive.

Approach 2. Writing Component Level Tests first

How can we address the following problems:

• The teams faced integration issues due to misunderstandings of Contracts

• The teams wrote invalid Component Level Tests, which didn’t protect them

Let’s look at the root causes and how this can be solved with the Test First approach:

• The reason for the late integration issues is that the teams were not aligned on their inter-team contracts (or perhaps they had misunderstandings regarding behavioral decomposition). To ensure that this problem is solved, we need to convert the failing Acceptance Test into failing Component Tests (and Contract Tests) so that it specifies what behavior each Component needs to satisfy and how each Component will integrate with other Components

• The reason why the Component Level Tests may be invalid with the Test Last approach is that we never saw them fail. To ensure that the tests are valid, we need to see them fail (for the right reason) before we start coding, i.e. Test First.

Problems solved with Component Level Tests first

By practicing TDD at the Component Level, we help ensure that:

• The teams are aligned in decomposing the behavior of an Acceptance Test into Component Level Tests, thus minimizing/eliminating late integration issues

• The teams have assurance that their tests are valid, because they saw the tests fail before implementing the code

TDD - Component Level - Component Tests

Here’s an overview of TDD at the Component Level.

As we can see, for one failing Acceptance Test, we need to see apply TDD within the Component.

Read more

Subscribe now

Component Level Testing provides effective Developer Facing feedback.

Component Level Testing is very useful for developers, because it provides the following:

• Commit Developer Feedback: Developers don’t have to wait for the slow-running Acceptance Tests (potentially, 1hr waiting time) to get feedback whether they introduced a regression bug. With Component Level Testing, the developer can get feedback within minutes whether they broke anything with their commit.

• Isolated Component Developer Feedback: Developers can get feedback whether their Component works in isolation from other Components and in isolation from External Systems. This means when we see we broke our Component, we can fix it ourselves, and don’t need to bother other teams.

  • The Frontend Developer can get feedback whether the Frontend works correctly in isolation (and whether it can communicate with the Backend), without actually spinning up the Backend.

  • The Backend Developer can get feedback whether the Backend works in isolation (and whether it can communicate with External Systems), without actually connecting to the External Systems.

  • In the case of Microservice Backend, the Developer can get feedback whether their Microservice works in isolation (and whether it can communicate with other Microservices), without actually spinning up the other Microservices.

But is this Developer Feedback fast enough?

Whilst Component Level testing is necessary & useful, it has some limitations with the feedback loop:

• Feedback is not fast enough: Component Tests are slow because they span I/O (e.g., a Backend Component Test involves I/O - hitting the Backend REST API, running with real DB in Testcontainers, running with WireMock/Pact to stub out external HTTP services). The more tests that there are, the more problematic this becomes. It’s challenging when there’s high business logic complexity, which can result in a large number of test cases, making the I/O slowness problem even more noticeable. This increased waiting time is a waste, it discourages us from running tests often, and reduces commit frequency. With decreased frequency of test execution, we may accumulate more regression bugs, and have to spend more time debugging.

• Feedback is not isolated enough: Component Tests span Presentation Logic, Business Logic, and Infrastructure Logic, so when those tests fail, we have to isolate whether the problem lies in Business Logic or Presentation/Infrastructure Logic. We don’t know, we have to debug.

📢 My next Live Q&A Session about TDD & Unit Tests is on Wed 18th Jun 17:00.

Register now

If you’re a Paid Member, you’ll receive 100% discount (see Event Description for instructions). If you’re a Free Member, you can upgrade now:

Subscribe now

Solution: Unit Level Testing

How can we get fast feedback for Business Logic, so that even if we have thousands of test cases, we can get feedback within milliseconds/seconds and not have to wait several minutes? How can we minimize the waiting time for developers? By reducing the waiting time, developers will be incentivized to run tests more often, thus commit more often. This enables developers to discover Regression Bugs ASAP, which then reduces the amount of time needed to fix the bug (since the change is still fresh in their mind). All this, combined, reduces total development time.

The Solution is:

• Unit Tests - testing Business Logic in isolation

• Narrow Integration Tests - testing Presentation Logic & Infrastructure Logic in isolation

For a system with Frontend & Monolithic Backend, we choose (separately) for Frontend and Backend whether we stay at just the Component Level or move down to the Unit Level. In the following example, we’ve chosen to stay at the Component Level for Frontend and decided to move to the Unit Level for Backend:

For a system with Frontend & Microservice Backend, we choose (separately) for the Frontend and each Microservice, whether we stay at the Component Level or go down to the Unit Level. In the following example, we’ve chosen to stay at the Component Level for Frontend; for microservices, for some we’ve chosen to stay at the Component Level, and for some we decided to go down to the Unit Level:

Read more

Subscribe now

I highly value discussions with Michaël Azerhad, I find his writing highly resonates with my perspectives on TDD in practice. I highly recommend you follow him on LinkedIn (some posts are in French, some in English) about TDD & related topics.

“Unit does not mean « unit of code », does not mean « don’t traverse more than a function ; mock all neighbors », does not necessarily means "small".“

…

“A unit test describes a behaviour, a « denouement », a « business scenario », and therefore there must be a kind of contravariance between tests and code.
Unit tests do NOT mirror the code!”

- Michaël Azerhad

There is a big confusion around Unit Testing (perhaps arising due to the Sociable Unit Tests vs Solitary Unit Tests approaches). So I collected some of Michaël’s posts below.

📢 My next Live Q&A Session about TDD & Unit Tests is on Wed 18th Jun 17:00. Here are some questions I’ll be answering based on Group Chat:

1. How to deal with unit tests & multithreading?

2. How to unit test abstract classes in libraries?

3. When we are testing Application Services (or Use Case Handlers) should we stub out Domain Services?

4. Which Test Doubles should we use in unit testing? (should we use mocking libraries or write our own test doubles)

5. Should we implement read methods on production repositories, just for test purposes?

6. How to handle non-halting errors?

7. Have an additional question? Add your question on Group Chat.

Register now

If you’re a Paid Member, you'll receive a 100% discount code (click on "Register now”; see Event Description for instructions). Upgrade to get the discount:

Subscribe now

Most developers do NOT know Unit Testing

Michaël Azerhad wrote a LinkedIn post about the most crucial thing that developers still don’t know - they don’t know the meaning of unit tests. A Unit Test should describe a behavior, it should be coupled to behavior rather than being coupled to code. That’s why we should avoid one-on-one mirroring of code through tests (a mistake that many developers make, creating a unit test per source code class)

By avoiding the mirroring, this enables you to refactor code without breaking tests:

To learn more about the dangers of “mirroring“, read the “One-to-One Correspondence.“ in Uncle Bob’s TDD Harms Architecture.

“Most people who are new to TDD, and the three laws, end up writing tests that look like the diagram on the left. They create a kind of one-to-one correspondence between the production code and the test code. For example, they may create a test class for every production code class. They may create test methods for every production code method.

…

The problem is – and I want you to think carefully about this next statement – a one-to-one correspondence implies extremely tight coupling.

…

It, frankly, took me many years to realize this. If you look at the structure of FitNesse, which we began writing in 2001, you will see a strong one-to-one correspondence between the test classes and the production code classes….

And, of course, we experienced some of the problems that you would expect with such a sinister design. We had fragile tests. We had structures made rigid by the tests. We felt the pain of TDD. And, after several years, we started to understand that the cause of that pain was that we were not designing our tests to be decoupled.”

- Uncle Bob

Clarification about the word “unit“ in Unit Testing

Michaël Azerhad wrote another LinkedIn post to further clarify the word “unit“, explaining the difference between Sociable and Solitary Unit Tests. In Classical TDD, Sociable Unit Tests tend to emerge:

He further explained why we should use Sociable Unit Tests (which are coupled to behavior and may traverse multiple classes) rather than Solitary Unit Tests (which are coupled to individual classes - units of code), it’s because it enables emergent design:

Michaël explained the historical problem of the word “unit“:

The following is a screenshot from Ian Cooper’s presentation:

“I call them “unit tests“, but they don’t match the accepted definition of unit tests very well” - Kent Beck, TDD by Example

“This is the only use of the phrase “unit test“ in the book, Kent is referring here to his use of the term “unit test” in casual conversation or by implication from xunit tools“ - Ian Cooper

“As you add new test functions to your suite, you add new behavior to your production code. Following the red-green-refactor process you extract that behavior into new functions and classes that do not require independent tests“

- Uncle Bob

Don’t couple tests to structure

I posted on LinkedIn to summarize this problem:

• If you write a test for every class, i.e. you’re testing every class in isolation, then your tests are mirroring your code. This structural coupling means if you change anything (e.g. move logic from one class to another, split a class, merge classes, change public interfaces of classes, etc.) then your tests will break

• On the other hand, if you write a test for a “module“ (it may span multiple classes), then your tests are not mirroring the code. You’re free to refactoring (change the module implementation, e.g. change the design of internal classes, their interfaces), BUT your tests won’t break

Leave a comment