🏆 Register now

🔒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

Component Tests are fast because they stub their dependencies

Component Tests give us fast feedback by testing a component in isolation.

The Frontend Team stubs out the Backend in Frontend Component Tests in Legacy Code; the Backend Team stubs out the External System (the ERP) in Backend Component Tests in Legacy Code.

But your stubs might be wrong!

When the Frontend stubs the Backend, it makes an assumption: “POST /api/orders returns 201 with { orderNumber }.”

But what if the Backend Team renames that field, or changes the status code, or moves the endpoint. What happens to the Frontend’s Component Tests?

They stay green. They’re still testing against the stub which hadn’t changed — but the stub’s assumption is now wrong.

The bug doesn’t show up until the Frontend and the Backend actually run together — when the Acceptance Test fails.

How to catch stub mismatch? Contract Tests

The Frontend says:

“This is what I expect from the Backend.”

Pact turns that expectation into a contract.

The Backend then runs the contract against itself.

If the Backend no longer matches what the Frontend expects, the Backend build fails.

You don’t write a new test from scratch. You take a Frontend Component Test you already have, and replace the stub with a contract.

Here are the steps to introduce Contract 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

One of the biggest mistakes I see in Spring applications is developers mocking JPA.

When tests become slow, they replace the database with mocked JpaRepository interfaces.

The tests are faster.

But the architecture is now coupled to the ORM.

Why Mocking JPA Is a Design Smell

Developers mock JPA because they want:

• fast tests

• no database

• isolated business logic

Those are good goals.

Mocking JPA isn’t.

Why?

• You’re mocking a framework you don’t own

• Your tests depend on Spring Data instead of your own abstractions

• Changing persistence forces you to change unit tests

• Business logic stays coupled to the ORM

The mock removes the database.

It doesn’t remove the dependency on the ORM.

The Real Problem

One team I worked with couldn’t upgrade their ORM for months because of a change to how inheritance was mapped.

The application wasn’t the problem.

The business logic wasn’t the problem.

The problem was that the ORM had leaked into the application layer and the tests.

A change in persistence rippled through the entire codebase.

A concrete example:

• In .NET, EF Core's Table-Per-Hierarchy inheritance auto-adds a Discriminator column, and its behavior has shifted across major versions — nullability, length, how it's configured and queried.

• An upgrade changes the discriminator, and that change ripples into every piece of code that touches those entities.

• JPA has the same trap: single-table inheritance auto-creates a DTYPE discriminator column, so a change to the mapping reaches straight into the application layer and its tests.

💡 Code Example

Read more

🏆 Register now

🔒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

Backend Component Tests provide fast feedback

We’ve seen in the previous article Backend Component Tests in Legacy Code, that Component Tests can provide us with fast feedback. The Backend Team can test the Backend in isolation, by stubbing out External Systems (such as the ERP).

But they can be a maintenance nightmare!

In Backend Component Tests in Legacy Code, we illustrated the “simplest” Backend Component Test.

The simplest way to write a Backend Component Test is to stub the External System inline (with WireMock), call the Backend API directly (with WebTestClient), and read the response by digging into raw JSON paths.

@Test
void shouldCreateOrderWithTotalPrice() {
    // Arrange
    var productDto = new ProductDto(2.50);
    var productDtoJson = objectMapper.writeValueAsString(productDto);
    erpWireMockStub.stubFor(WireMock.get(“/products?sku=APPLE1001”)
        .willReturn(WireMock.aResponse()
            .withStatus(200)
            .withHeader(“Content-Type”, “application/json”)
            .withBody(productDtoJson)));

    var orderRequest = new OrderRequest(“APPLE1001”, 5);

    // Act & Assert
    webTestClient.post()
        .uri(“/api/orders”)
        .contentType(MediaType.APPLICATION_JSON)
        .bodyValue(orderRequest)
        .exchange()
        .expectStatus().isCreated()
        .expectBody()
        .jsonPath(“$.totalPrice”).isEqualTo(12.5);
}

The problem is that this test is coupled in three places at once: the ERP wire format (the WireMock stub), the Backend API endpoint (webTestClient.post().uri("/api/orders")), and the response (the raw $.totalPrice JSON path).

If the API endpoint changes, or the ERP’s wire format changes (a renamed field, a different status code), then many such tests may break, so we have to waste time fixing tests. The plumbing is also copy-pasted into every test.

How to write maintainable Backend 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 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

The mistake is to look at the finished use case — availability check, number generation, persistence, a response — and write all of it in one go.

That’s not TDD.

That’s writing the answer and then sprinkling tests on top.

TDD is incremental: write the simplest behavior that could possibly work, get it green.

The next failing test decides what gets added next.

Behavior 1: a guest can reserve a room

Requirement:

“Guest can reserve a room.”

Notice what’s not in that sentence yet: nothing about availability. So we don’t build availability checking. We build the smallest thing the requirement asks for — a reservation gets added, and we get a reservation number back.

🔴 RED — Write the failing test

class PlaceReservationTest {

    private FakeReservationRepository reservationRepository;
    private StubReservationNumberGenerator reservationNumberGenerator;
    private PlaceReservationUseCase placeReservationUseCase;

    @BeforeEach
    void setUp() {
        reservationRepository = fakeReservationRepository();            // fake — in-memory, query state back
        reservationNumberGenerator = stubReservationNumberGenerator();  // stub — canned number
        placeReservationUseCase = new PlaceReservationUseCase(
            reservationRepository, reservationNumberGenerator);
    }

    @Test
    void createsReservation() {
        reservationNumberGenerator.returns("RES-123");

        var placeReservationRequest = PlaceReservationRequest.builder()
            .guestId("guest-1")
            .roomId("room-101")
            .build();

        var response = placeReservationUseCase.execute(placeReservationRequest);

        assertThat(response.reservationNumber()).isEqualTo("RES-123");

        var reservation = reservationRepository.findByReservationNumber("RES-123");
        assertThat(reservation.guestId()).isEqualTo("guest-1");
        assertThat(reservation.roomId()).isEqualTo("room-101");
    }
}

Notice what exists so far:

• repository to add the reservation

• number generator so the test can pin the returned number (RES-123) deterministically.

There is no AvailabilityGateway — nothing requires one yet.

Look at the request, too: it only has a guest and a room — no dates. A real reservation obviously has dates, but no behavior here uses them yet, so they’re not in the request yet.

The requirement was “reserve a room,” nothing about when. You add data for the same reason you add code: when a test needs it, not before.

🟢 GREEN — Make it pass with the simplest code

public class PlaceReservationUseCase {

    private final ReservationRepository reservationRepository;
    private final ReservationNumberGenerator reservationNumberGenerator;

    public PlaceReservationUseCase(ReservationRepository reservationRepository,
                                   ReservationNumberGenerator reservationNumberGenerator) {
        this.reservationRepository = reservationRepository;
        this.reservationNumberGenerator = reservationNumberGenerator;
    }

    public PlaceReservationResponse execute(PlaceReservationRequest request) {
        var reservationNumber = reservationNumberGenerator.next();

        reservationRepository.add(new Reservation(
            reservationNumber,
            request.guestId(),
            request.roomId()
        ));

        return new PlaceReservationResponse(reservationNumber);
    }
}

Green. It always adds the reservation — it never checks anything — because no test has demanded a check yet.

This feels too simple, and that’s the point. You are not allowed to add the availability logic now. There’s no failing test pushing you there.

🔵 REFACTOR — only if you see the need

With the test green, you now get a safe moment to improve the design — rename, extract, remove duplication — without changing behavior. You take it only if you actually see an improvement worth making; if nothing stands out, you skip it and move on.

Here the use case is a few straight-line statements with nothing to tidy, so there's nothing to do.

Behavior 2: only if the room is available

Now a new requirement arrives:

“A room can only be reserved if it is available for the selected dates.”

Now we need to know if the room is available.

🔴 RED — Write the failing test

    @Test
    void rejectsReservationWhenRoomIsUnavailable() {
        availabilityGateway
            .forRoom("room-101")
            .from("2026-07-10")
            .to("2026-07-12")
            .returnsUnavailable();

        var placeReservationRequest = PlaceReservationRequest.builder()
            .guestId("guest-1")
            .roomId("room-101")
            .from("2026-07-10")
            .to("2026-07-12")
            .build();

        assertThatThrownBy(() -> placeReservationUseCase.execute(placeReservationRequest))
            .hasMessage("Room is not available");
    }

Read more

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.