Subscribe now

Most developers test the same behavior twice.

Once through the API.
Once through the UI.

Two separate tests suites.
Two sets of assertions.
Double the maintenance costs.

And sooner or later?…

The API tests pass.
The UI tests fail randomly.
Nobody fully trusts either.

⚠️Duplication is risky

If you test both channels, you end up with two completely separate test suites:

• An API test suite that sends HTTP requests and checks JSON responses

• A UI test suite that drives a browser with Selenium or Playwright

Same scenarios. No shared structure. No shared assertions.

When a requirement changes, you update two tests instead of one.

Worse — the two suites start contradicting each other.

The API tests check one set of scenarios.
The UI tests check a slightly different set.

Gaps appear. Bugs hide in the gaps.

Want to skip the pain and go straight to the solution?

I’m running a live, hands-on workshop where we build acceptance tests that run against both the API and UI — compile-time safe, IDE-guided and refactor-proof.

Join the workshop →

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

💡What Changed Everything for Me

Instead of writing the same test twice…

Read more

Subscribe now

Every time I write about acceptance testing, someone asks:

This makes sense. But how do I actually start?

I’ve gotten this in DMs. In comments. In conversations with Tech Leads.

They understand why acceptance tests matter.
They’ve felt the pain of shipping bugs.
They’ve read about ATDD.

But when they sit down to actually write one?

They stare at a blank file and think:

• Where do you put the acceptance tests?

• How do you structure them so they don’t become as fragile as the E2E tests you’re trying to replace?

• How do you design them so your whole team can write and maintain them — not just the one person who “gets testing”?

You want tests that are:

Clean. Readable. Runs in seconds. Survives refactors.

But…

• How do you build the DSL that makes it work?

• How do you wire up the Drivers that connect these tests to your actual system?

• How do you structure all of this so it scales across your whole team?

Hands-On Acceptance Testing

That’s why I built a live, hands-on workshop.

This isn’t a course you watch alone at 2x speed and forget by Friday.

What you’ll learn:

1. The architecture. How acceptance tests are structured — DSL, Drivers, the layers that make them maintainable. You’ll understand why some acceptance tests become unmaintainable spaghetti and yours won’t.

2. ATDD Cycle with AI. We’ll design an acceptance test together — from a business scenario all the way through to verification. You’ll get to see the layers (DSL & Drivers) in practice.

3. Apply it with your team. How to introduce acceptance testing into an existing project without stopping everything. How to get buy-in. How to start.

When: May 25–26, 2026 | 2-4 PM CET
(FYI: May 27–28 | 5-7 PM CET — Fully Booked)
Where: Live on Zoom
Duration: 4 hours (2 sessions x 2 hours)

💻 Who it’s for: Senior Engineers and Tech Leads who are tired of shipping bugs and ready to do something about it

🚀 Register: ATDD – Acceptance Testing Workshop
Get €100 off with code EARLYBIRD100

Don’t spend next month debugging something that should have been caught before it shipped.

Join the workshop →

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

Subscribe now

This test doesn’t lie:

scenario
    .given().product().withUnitPrice(20.00)
    .and().country().withCode("US").withTaxRate(0.08)
    .when().placeOrder().withQuantity(5).withCountry("US")
    .then().shouldSucceed()
    .and().order()
        .hasBasePrice(100.00)
        .hasTaxAmount(8.00)
        .hasTotalPrice(108.00);

Clean. Readable. Runs in seconds. Survives refactors.

But how does it actually work?

What’s behind .given().product().withUnitPrice(20.00)? How does the same test run against both the API and the UI? Where does the “magic” come from?

I’m going to take this test apart, layer by layer, and show you exactly how the DSL is built.

⚡Ready to see this in action?

I’m running a live, hands-on workshop where we build acceptance tests using this exact architecture. 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

The four layers

An acceptance test DSL has four layers. Each layer has one job, and they only talk to the layer directly below them:

Test           →  what we're testing (the scenario)
DSL            →  how we express it (the fluent API)
Driver Port    →  what we need from the system (interfaces)
Driver Adapter →  how we interact with the system (API calls, browser clicks)

This separation is the entire reason acceptance tests are maintainable. Remove any layer and the whole thing falls apart.

Layer 1: The Test

This is what you’ve already seen. A test method that reads like a business scenario:

@TestTemplate
@Channel({ChannelType.UI, ChannelType.API})
void shouldCalculateCorrectTotalWithTaxRate() {
    scenario
        .given().product()
            .withUnitPrice(20.00)
        .and().country()
            .withCode("US")
            .withTaxRate(0.08)
        .when().placeOrder()
            .withQuantity(5)
            .withCountry("US")
        .then().shouldSucceed()
        .and().order()
            .hasBasePrice(100.00)
            .hasTaxAmount(8.00)
            .hasTotalPrice(108.00);
}

Notice what’s not here:

• No URLs

• No HTTP calls

• No CSS selectors

• No database queries

• No setup or teardown

The test only knows what it’s testing. It has no idea how the system works under the hood. That’s the point.

The @Channel annotation is interesting — it tells the test runner to execute this same test once through the API and once through the UI. Same scenario, same assertions, two completely different ways of talking to the system. Here’s how it actually works.

Read more

Subscribe now

Marco stared at the Slack message from support.

“Customer says they were charged $110 on a $100 order. Tax should have been $8, not $10.”

He pulled up the dashboard. All tests green. CI/CD pipeline — clean. Not a single failure in weeks.

And yet, the tax calculation was wrong.

Marco spent the next hour tracing the bug. The tax calculation itself was correct. The unit test proved it: pass in a rate, get back the right amount. No issues there.

The problem was simpler than that. And worse.

The developer who built the order service had hardcoded the tax rate as a constant — 10% — while working on the feature. The plan was to pull it from the country configuration later.

But “later” never came.

The feature shipped, the tests passed, and nobody noticed.

The unit test for the tax calculation? It tested the math. And the math was right. 10% of $100 is $10. Test passes.

But the feature was wrong. The customer was in a state with an 8% tax rate, and the system charged 10% because it never actually looked up the rate.

E2E tests? They had those too. But the E2E test just checked that the confirmation page appeared after placing an order. It never verified the actual total.

The feature was broken. And no test caught it.

Here’s the uncomfortable truth most teams don’t talk about:

Unit tests verify that individual components work. They can’t tell you whether the feature works. Marco’s tax calculation was correct — it just used the wrong input.

E2E tests verify the happy path through the UI. But they’re slow, fragile, and they often check that something shows up on screen, not that the right thing shows up.

There’s a massive gap between “all my unit tests pass” and “this feature actually works as the customer expects.”

That gap is where your production bugs live.

There’s a test type that fills this gap

It’s called an acceptance test.

Not another E2E test. Something fundamentally different.

An acceptance test is an executable specification of system behavior. It answers one question: does this feature work the way the business expects?

Here’s what Marco’s E2E test looked like:

@Test
void testPlaceOrder() {
    driver.get(baseUrl + "/products");
    driver.findElement(By.id("product-1")).click();
    driver.findElement(By.id("add-to-cart")).click();
    driver.findElement(By.id("quantity")).sendKeys("5");
    driver.findElement(By.id("checkout")).click();
    driver.findElement(By.id("place-order")).click();

    WebElement confirmation = driver.findElement(By.id("confirmation"));
    assertTrue(confirmation.isDisplayed());
}

Brittle. Tied to the UI. Breaks if someone renames a button. And it only checks if the confirmation page shows up — it never verified the actual total.

Here’s the same scenario as an acceptance test:

@Test
void shouldCalculateCorrectTotalWithTaxRate() {
    scenario
        .given().product()
            .withUnitPrice(20.00)
        .and().country()
            .withCode("US")
            .withTaxRate(0.08)
        .when().placeOrder()
            .withQuantity(5)
            .withCountry("US")
        .then().shouldSucceed()
        .and().order()
            .hasBasePrice(100.00)
            .hasTaxAmount(8.00)
            .hasTotalPrice(108.00);
}

No browser. No CSS selectors. No flaky waits.

Just a clear business scenario: given a product at $20, a quantity of 5, and a country with 8% tax — the base price should be $100, the tax should be $8, and the total should be $108.

This test would have caught Marco’s bug immediately. The system would return a total of $110 instead of $108 — test fails. The hardcoded constant would have been found before it ever reached a customer.

Marco’s team? After they introduced acceptance tests, customer-reported bugs dropped dramatically in the first few months. Not because they wrote more tests — but because they wrote the right tests.

Want to learn how to write tests like this?

I’m running a live workshop: Stop Shipping Bugs: Acceptance Tests Workshop.

4 hours. Two evenings. Live on Zoom, with me.

⚡I’ll walk you through the full architecture — DSL, Drivers, how it all fits together — and by the end, you’ll have written a real acceptance test from scenario to assertion.

📅 May 27-28, 5:00-7:00 PM CET

Join the workshop →

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

— Valentina

Subscribe now

If you’ve ever written acceptance tests in plain-text Gherkin, you probably had the same thought I did:

“This looks clean… so why is it so painful to maintain?”

Gherkin was supposed to let product owners write specifications.

But in reality?

Almost never happens.

Developers write the .feature files.
Developers maintain them.
Developers debug them at runtime.

Most teams follow the usual setup: they write Gherkin scenarios in .feature files using Cucumber (Java), SpecFlow (.NET) or Cucumber.js (TypeScript).

At first glance, it looks great:

English sentences.
Given / When / Then.

But…

⚠️The Hidden Cost of Textual Gherkin

Scenario files look readable, but become a maintenance burden:

Scenario: Calculate base price as product of unit price and quantity
  Given a product with unit price $20.00
  When an order is placed for that product with quantity 5
  Then the order placement should succeed
  And the order base price should be $100.00

Duplication everywhere

That sentence in the .feature file?

You repeat it again in step definitions (“glue code“).

Change one word?
Now you change it in multiple places:

• Change it in the step definition

• Change it in all affected test scenarios

Typos = runtime failure

Misspell a word?

You won’t know until you run the test.

The compiler doesn’t help you.

Your IDE doesn’t help you.

You only find out after everything compiles… and then fails.

You’re on your own.

No auto-complete.
No “what comes next?”
No guardrails.

You have to remember exact sentences.

And nothing prevents you from:

• Writing two When steps

• Writing steps that don’t exist

• Mixing domain concepts accidentally

It’s fragile by design.

Want to skip the pain and go straight to the solution?

I’m running a live workshop where we build acceptance tests that are compile-time safe, IDE-guided, and refactor-proof — no .feature files, no glue code.

Join the workshop →

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

💡What Changed Everything for Me

Instead of writing English sentences and matching them with strings…

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 used to hate writing acceptance tests.

I’d spend hours writing tests that either:

• failed for silly reasons (“Did I spell that parameter right?”), or

• passed even though they shouldn’t (“Why is this green? That’s broken!”)

It was frustrating, demotivating, and exhausting. And the worst part? I wasn’t even learning anything from the tests.

The Old Way: What I used to do

Here’s a typical test I used to write:

@Test
@Channel(UI, API)
public void shouldPlaceOrder() {
    erp.setupProduct("sku: ABC", "unitPrice: 2.00");
    shop.placeOrder("orderNumber: ORD-1001", "sku: ABC", "quantity: 5");
    shop.assertOrderDetails("orderNumber: ORD-1001", "totalPrice": "10.00");
}

• Parameter names everywhere—I had to remember exact strings like “InvoiceSubmitter1” or “invoice1”. One typo and the test failed or, worse, passed incorrectly.

For errors, I’d need to have try/catch:

@Test
@Channel(UI, API)
public void shouldNotBeAbleToPlaceOrderWithNegativeQuantity() {
    try {
        erp.setupProduct("sku: ABC", "unitPrice: 2.00");
        shop.placeOrder("orderNumber: ORD-1001", "sku: ABC", "quantity: -2");
    } catch(Exception ex) {
        assertEquals("Quantity must be positive", ex.getMessage());
    }
}

• Too much try/catch—I had to catch exceptions just to check if something failed.

Sound familiar?

It worked…sort of. But it was frustrating.

Writing Tests Without the Headache

I realized the problem wasn’t testing itself.

The problem was how I was writing the tests.

I wanted the IDE to guide me while writing tests—so mistakes show up at compile time, not during a test run.

Read more

Subscribe now

This post is sponsored by testRigor, the #1 Generative AI-based Test Automation Tool.

The problem with Manual QA Testing

Many teams are still stuck with manual regression testing. QA Engineers document test procedures in Word, Confluence, etc., and spend most of their time executing tests. This is repetitive, slow, and error-prone.

For example, a two-week manual QA cycle often repeats: QA finds regression bugs → developers fix the regression bugs → QA retests → QA discovers new regression bugs. This can continue indefinitely. Consequently, these problems occur:

1. Slow Delivery - Manual regression testing cycles take too long, which delays the entire delivery process. Business is frustrated, blaming IT for being too slow.

2. Production Bugs - Due to release deadlines, timeboxed testing means some tests are skipped, letting regression bugs reach production.

3. Compliance Risks - In highly regulated industries (e.g., medical/healthcare), manual screenshot documentation slows down QA and risks human error and non-compliance.

4. Salary Costs - As the software grows, the number of regression bugs increases. Companies have to hire more QA engineers just to keep up, but it’s never enough.

Why Test Automation is too expensive

Attempt 1: E2E Tests with Selenium (or Playwright, Cypress, etc.)

Companies may buy record-and-play tools that generate Selenium E2E tests, or their QA Automation Engineers write Selenium tests by hand.

But these tests are fragile since they’re tightly coupled to implementation details. Small UI changes (e.g., changing a button’s CSS) can break many tests, forcing QA Automation Engineers to spend a lot of time fixing up those failing tests, leaving little time to test new functionality. For example, a company may have automated 30% of tests in the first year, 35% of tests in the second year, but then stalled because maintenance costs were too high.

Attempt 2: E2E Tests with AI Tools

Writing and maintaining Selenium Tests was too expensive, so teams turned to AI tools that looked promising - you could write the tests in plain English, instead of Selenium. Manual QA Engineers could automate tests without QA Automation Engineers.

But those AI tools may lack abstraction, i.e., be coupled to UI implementation details (XPath or CSS Selectors), so UI changes break the tests.

Even worse, when the tool can’t find a UI element, it falls back to using AI. But AI can hallucinate—generate incorrect or misleading test results that require human intervention to fix—which can be more expensive than manual testing. For example, AI can give the wrong coordinates of an element.

Why Test Automation doesn’t solve high rework cost

Traditional test automation happens after code is written. If QA discovers developers misinterpreted specs, it’s too late. QA Automation Engineers end up writing tests that follow the implementation, even though it’s wrong. When misinterpretations are caught, developers have to fix the code, and QA Automation Engineers have to play catch-up by updating the tests.

Meanwhile, the team is working on the next sprint, so the QA Automation Engineer is now both catching up on existing features and writing tests for new ones. This is not sustainable.

ATDD is the solution

1. Tests must be abstracted away from implementation details. We want to write tests in plain English — not tied to CSS selectors or XPath.

2. Tests should be written before coding starts. We want to ensure that the whole team (PO, Developers, QA Engineers) is aligned on the specifications before coding begins, to avoid costly rework later.

With ATDD, we start with a specification, convert it into an executable specification (acceptance test), and write code to make the tests pass. Thus, with ATDD, test automation is done before coding. You write executable specifications in plain English, so Product Owners can review and correct them before the developers start coding. This step alone can save 30–35% of engineering time due to precise requirements.

ATDD with the Four Layer Model

The most well-known approach for ATDD uses Dave Farley’s Four Layer Model. Tests are written in a DSL decoupled from implementation, thus the tests are readable as requirements. The DSL calls Drivers, e.g., Web UI Drivers (using Selenium with XPath/CSS), API Drivers (using HTTP Client), Mobile App Drivers, CLI Drivers, etc. Furthermore, by annotating tests with channels, we can write a test once and execute it against multiple channels.

Designing this maintainable Acceptance Test Architecture requires a strong design skillset and time investment. Anyone can write these tests (e.g., QA Engineer), but Developers need to maintain the “plumbing” (DSL, Channels & Drivers) and fix test failures. In case of changes to the UI, Developers need to update Drivers without having to change tests; this helps reduce maintenance costs.

The reality is that in many teams, executives want results “right now”; they want to immediately convert their whole Manual QA Test Suite into automated testing. This can’t be done overnight with the Four Layer Model.

ATDD with testRigor

In testRigor, tests are written in plain English, decoupled from UI implementation details. Manual QA Engineers can write the tests themselves. There’s no “plumbing” code, which means that (1) Developers and QA Automation Engineers aren’t needed to write tests, (2) when developers change the UI, the tests don’t have to be changed.

When adopting ATDD with testRigor, QA Engineers write a failing test in plain English, and developers can write code (or let testRigor generate code) to make the test pass.

Note: testRigor usually detects UI elements from plain English steps. If it fails, you can add custom code, creating “plumbing” to maintain. The amount of maintenance needed depends on your product and how often custom detection is required.

Phase 1 - Migrating Manual Tests to testRigor

Manual QA Engineers can import their Manual Test Procedures into testRigor (which recognizes plain-English steps). We can connect testRigor to our test source (e.g., JIRA / TestRail, etc.), or we can create the tests ourselves in testRigor.

Note: If we do not have documented test cases, we can use testRigor to generate test cases by providing our application URL and a description of the application domain. Then testRigor uses AI to generate the test cases.

We can view and edit the imported tests, e.g., ‘Find and add Kindle to the shopping cart’:

Above, several steps were successfully recognized by testRigor, and are thus able to be executed deterministically (no AI involved).

However, when a step is not recognized (e.g., the last one), we can fall back to AI by clicking “Use AI to complete creating this test”:

Then AI generates UI steps for the unrecognized custom step above:

The QA Engineer can review and correct the generated steps. When AI “hallucinates”, the QA Engineer can manually correct steps. After the QA Engineer’s cleanup, here’s the updated test:

The test passes!

Note: This new step becomes a reusable step, recognized when parsing further Manual QA test procedures, even if sentences aren’t identical.

To summarize, we import a batch of Manual Test Procedures, clean them up, and then repeat with the next batch. This means we can quickly automate a high percentage of Manual Tests.

Phase 2 - Applying ATDD with TestRigor

RED - Write the failing test

For a user story, write testable acceptance criteria. Based on this, the QA Engineer writes a test in plain English, and inputs it into testRigor. As testRigor executes the test, the QA Engineer can edit custom steps. If AI hallucinates, the QA Engineer can make corrections and clean up the steps, then ask AI to continue until the test is successfully written down.

When testRigor runs the test, it should fail because the functionality isn’t implemented yet - causing testRigor to report an error:

Note: When writing Acceptance Tests, we need to stub out external systems. To support us, testRigor provides a way to mock APIs on the network, see mocking api calls.

GREEN - Write the code to make the test pass

We can use testRigor to generate code to make the tests pass. For a failing test, click “Fix code for me” so that AI can generate the necessary code:

testRigor generates code and checks if the test passes. If the test still fails, testRigor retries until the test passes. Finally, the test passes:

REFACTOR - Refactor the code

After the test passes, testRigor creates a PR for a developer to review the generated code. The developer may review and/or refactor the code.

How can you overcome AI limitations with testRigor?

testRigor is fully AI-first, letting QA Engineers correct hallucinations in plain English and continue building tests. Its AI framework handles hallucinations automatically for single-step actions, enabling testing of charts, diagrams, AI features, and previously untestable apps like Flutter, Citrix, Oracle EBS, and games.

You don’t need to learn any prompting techniques - testRigor will do it for you. All you need is to be crystal clear on what exactly needs to be done. testRigor will do all the AI tricks for you and will correct the hallucinations in 99.95% of the cases for one-step scenarios.

What are the time savings with testRigor?

Development time is reduced:

• testRigor enables ATDD, and because there is no reliance on implementation details, you can write tests before developers write code → using ATDD saves 35% of development time on rewriting by reducing requirement gaps

• testRigor generates code until the test passes and creates a PR for developers to review, so they can interact with it like with another developer by providing code reviews

QA Time is reduced:

• testRigor lets QA Engineers import manual tests from test management systems

• testRigor lets Manual QA Engineers build test automation 4.5 times faster than professional QA Automation Engineers (see IDT Case Study)

• QA time is reduced because testRigor generates test steps (based on the test description inputs by the QA Engineer), and then the QA Engineer reviews the test

• Test maintenance is almost eliminated since tests don’t rely on implementation details

Compliance risks are reduced:

• testRigor is HIPAA compliant, esp. helping medical companies automate 21 CFR Part 11 Compliance 4 - enabling automation on all media, including Web, Native Mobile, Native Desktop, Mainframes, API, Phone call, Text messages, 2FA authentication, etc

How IDT achieved 90% automation with testRigor?

IDT achieved 90% automation in one year using testRigor. You can watch the video How IDT was able to achieve 90% automation in under a year with testRigor and read the case study How IDT Corporation went from 34% automation to 91% automation in 9 months.

Try out testRigor

👉 Request a demo — and see how testRigor can help your team automate manual tests and start with ATDD.

Use the code “VALENTINA42” to get a 10% discount.

This post is sponsored by testRigor, the #1 Generative AI-based Test Automation Tool.

Subscribe now

End‑to‑end (E2E) tests are supposed to be the safety net that proves a product actually works as expected.

In practice, many E2E suites become slow, brittle, and expensive to maintain — full of fragile selectors, flaky assertions, and tests that depend on uncontrollable external systems. Teams end up with a noisy test pipeline that slows delivery and provides little real confidence.

Let’s look at why typical E2E tests fail teams more often than they help, using a concrete example of a price‑calculation test that flounders because of ERP dependencies, brittle UI locators, and vague assertions.

🟠 Problem #1: Limited verification

🟠 Problem #2: Fragility

🟠 Problem #3: Poor readability

Then, we’ll see a pragmatic alternative: move precise verification into unit and integration tests, isolate external systems with test doubles or contract tests, and keep E2E tests narrow, resilient, and intent‑focused.

Read on for practical patterns, concrete refactor examples, and a checklist for making tests reliable, readable, and low‑maintenance — so testing becomes a productivity multiplier instead of a drag on delivery.

Typical bad E2E Test

@Test
void shouldCalculateOriginalOrderPrice() {
    // Act
    page.navigate(baseUrl + “/shop.html”);

    var productIdInput = page.locator(”[aria-label=’Product ID’]”);
    productIdInput.fill(”HP-15”);

    var quantityInput = page.locator(”[aria-label=’Quantity’]”);
    quantityInput.fill(”5”);

    var placeOrderButton = page.locator(”[aria-label=’Place Order’]”);
    placeOrderButton.click();

    // Wait for confirmation message to appear
    var confirmationMessage = page.locator(”[role=’alert’]”);
    confirmationMessage.waitFor(new Locator.WaitForOptions().setTimeout(TestConfiguration.getWaitSeconds() * 1000));

    var confirmationMessageText = confirmationMessage.textContent();

    var pattern = Pattern.compile(”Success! Order has been created with Order Number ([\\w-]+) and Original Price \\$(\\d+(?:\\.\\d{2})?)”);
    var matcher = pattern.matcher(confirmationMessageText);

    assertTrue(matcher.find(), “Confirmation message should match expected pattern. Actual: “ + confirmationMessageText);

    var totalPriceString = matcher.group(2);
    var totalPrice = Double.parseDouble(totalPriceString);
    assertTrue(originalPrice > 0, “Total price should be positive”);
}

Problem #1: Limited verification

When the user places an order for a SKU and quantity, we need to lookup order price from the ERP.

Unfortunately, the ERP does not allow us to control unit prices.

Therefore, we can’t assert the total price value. We can only do a weak assertion that it’s positive.

assertTrue(originalPrice > 0, “Total price should be positive”);

Read more

Subscribe now

As I was building a template generator - a task that should be very simple - I first gave the manual procedure to Copilot to implement. It implemented it wrong.

As I’m running the first cohort of ATDD Accelerator for 2025, because it’s practical, one of the first things we do, is TDD sandbox setup. Now, the trouble is that even setting up a simple project takes time. Setting up a pipeline takes time.

So I thought, to make it easier for everyone, I’d make a template. It’s a multi-language template, and I’m basically automating it. To automate this, I have a GitHub template, and I want to automate the process of creating a new repository from that template and then doing some post-processing on top.

The Simple Task That Wasn’t So Simple

First, I documented everything manually through my quickstart. Then I wanted to automate it. I went with PowerShell. And since I’m not really an active PowerShell user, I decided to use Copilot to help me generate the code. I gave it the quickstart, it generated the script, I ran it - and it didn’t work.

I thought, “Well, it’s simple. I’ll spend a few hours and get it to work.” But what happened was, as I was trying to get it to work, every time I needed to do manual testing: open up the generated repository in GitHub, check which folders were there, verify if substitutions were done or not, and then manually delete the repository.

None of this was complex - it was simple, repetitive work - but it ended up taking me hours. And after all those hours, I still didn’t have anything actually working.

AI Wrote Meaningless Tests

So I thought, “Okay, let’s try AI again. Maybe I should start with tests first.” I gave Copilot the quickstart and asked it to generate test cases. It generated lots of them, but when I looked, many were meaningless. Some were too tightly coupled to the setup steps in my quickstart, and not really asserting end results. And the tests were hard to read.

Back to Basics: The First Test

That was the wake-up call. ATDD isn’t just for big company projects - it applies even here. Even for this silly, simple script, ATDD is the way to go.

So I scrapped everything Copilot had done before and started over. I wrote the very first test - “hello world,” basically just checking if the repository was even created. Then I added the next test, verifying whether a certain folder exists or doesn’t exist after post-processing. And then I asked the AI to make the test pass.

At first, Copilot generated way too much code - more than was needed to make the test pass. Then I refined the prompts to ask it for only the minimal code required. That worked better.

Slow Start, Fast Momentum

Yes, the first setup took time. Writing those first tests, creating the DSL for interfacing with GitHub CLI, wiring it up to the template generator script, and setting up GitHub Actions - all of that took hours. It was slow in the beginning. But once the foundation was in place, writing the next test was super fast - within a minute I could write the test and then have the AI generate just enough code to pass it.

So that’s how I accelerated my own development: on one hand, I built maintainable acceptance tests, which made it cheap to add the next test. On the other hand, I minimized coding time by using Copilot incrementally. Ultimately, that reduced overall development time.

🚀 Join the ATDD Accelerator waitlist

• Hesitate to change code because you fear breaking something

• Spent hours debugging a failure in a system you barely understand

• Tried adding automated tests to an old system only to give up in frustration

…then you already know the core problem: testing legacy code is hard.

But here’s the thing - it doesn’t have to be that way.

Why Teams Struggle With Legacy Code

I’ve spent years coaching teams that ship changes to fragile, business-critical systems. Most of those teams avoided changing code in certain areas because “it’s too risky.” They also relied on Manual QA to verify those “risky“ changes.

They didn’t trust automated tests. The irony? That’s exactly where tests are most needed.

Over the years, I’ve developed and refined a safe, incremental approach to Acceptance Test-Driven Development (ATDD) for legacy systems - one that can improve quality without slowing delivery.

This helps engineering teams to escape legacy code, even in high-pressure environments.

What You’ll Learn

In this free live Lightning Lesson, I’ll show you:

• Why Unit Tests & E2E Tests don't protect us in production

  Discover why many test automation initatives fail in reducing regression bugs

• Implement User Stories without breaking functionality

  Deliver new business features while preserving the stability of existing workflows

• Fix Bugs without causing new Regression Bugs

  Resolve defects in a way that prevents regressions and unintended side effects

• Redesign the UX/UI whilst whilst keeping the system working

  Refresh the user interface and experience without disrupting core system behavior

• Modernize your System Architecture & Tech Stack safely

  Upgrade legacy architecture incrementally while ensuring ongoing reliability and business continuity

Event Details

📅 Date & Time: Wed, Sep 24, 2025 5:00PM
📍 Where: Live on Maven (online)
💰 Cost: Free

🔗 Register here: Stop Breaking Production: ATDD in Legacy Code

Who Should Join

This lesson is for Engineering Managers, Tech Leads & Senior Software Engineers working with legacy systems who want to improve quality without introducing new risks. Whether you’re new to ATDD or looking for ways to apply it in challenging environments, you’ll leave with actionable strategies you can use immediately.

Meet Your Coach

I’m Valentina - a technical coach and former software engineer who’s spent years helping teams adopt modern quality practices in complex legacy systems. I’ve guided teams to reduce production bugs and accelerate delivery.

I built this Lightning Lesson to give you practical techniques - not abstract theory - so you can finally stop fearing your legacy codebase and start improving it.

Break Free From Legacy Code

If you want to:

• Ship changes with confidence

• Catch regressions before they cause trouble

• Build tests that actually protect your system

…then I’ll see you in the live session.

📌 Register here: Stop Breaking Production: ATDD in Legacy Code

Register now

Subscribe now

The business wanted it done yesterday - and deployed today.

The dev is told: “I don’t care how, just get it working.”

But that speed comes at a cost: messy code.

So what do we do?

We take shortcuts. We write dirty code. We skip design decisions. And in many cases - that’s completely okay.

You don’t need to start with Unit Tests

It’s not possible to write unit tests if there’s high coupling between business logic and I/O logic. And even worse - many developers write fragile unit tests that are tightly coupled to internal implementation details. So when the design changes, those tests break, and developers have to rewrite them. And there’s no time for this.

But even effective unit tests break when you change the public API (whereas bad unit tests also break when you change the internal implementation). If you redesign the API, the tests still have to be updated.

So does that mean we have to skip tests entirely?

No — it means we need a different kind of test.

Acceptance Tests Don't Care About Messy Code

Unlike unit tests, acceptance tests stay stable - they only care about user behavior.

Acceptance tests validate user-facing behavior, not developer-facing behavior.

That means, for Acceptance tests:

• It doesn’t matter how messy your code is.

• It doesn’t matter if your architecture is bad.

• As long as the functionality works — the Acceptance test passes.

So even if you're delivering fast and writing quick-and-dirty code to get things working — your acceptance tests still give you assurance that the system behaves correctly.

Clean It Up Later (Without Fear)

Let’s say you come back in a few sprints. You now understand the domain better. You’ve seen how the code evolved. You’re ready to clean up the mess.

Great. Because your acceptance tests are stable, you can redesign, refactor, and re-architect — without breaking the acceptance tests. They still describe the same user-facing behavior, regardless of how the code underneath is structured.

Defer Design Decisions - The Power of ATDD

• Start with user behavior and write high-level acceptance tests

• Implement quickly - even with “dirty” code

• Refactor and improve the design later, with full test protection

That’s why ATDD is powerful: you can ship fast, defer clean-up, and still have confidence your system works.

Protect behavior first - with high-level acceptance tests. Improve your architecture & design later.

Want to Learn How?

How can you introduce acceptance tests into your development process?

See the TDD in Legacy Code series, where we have a section ATDD in Legacy Code.

Want the full roadmap? I'm hosting a workshop breaking down exactly how to implement this. I’ll show you how to align the team regarding requirements and eliminate manual QA regression testing, so that you’ll reduce delivery time and reduce regression bugs.

🚀Join me on Wed 6th Aug (17:00 - 19:00 CEST), I’m hosting ATDD in Legacy Code Roadmap (Live Workshop). During this workshop you’ll learn:

1. Why ATDD will reduce software delivery time and reduce regression bugs, by aligning the team regarding requirements & replacing manual regression testing

2. How to introduce ATDD in Legacy Code in an incremental way, while still keeping up with existing feature delivery

3. How to convince Engineering Managers, Software Engineers and QA Engineers to adopt ATDD in Legacy Code

Let's transform your development process together!

🏆 Register now

P.S. Regular price: $97 (free access for Optivem Journal paid subscribers - see event description for details)

Subscribe now

If your team is stuck in a legacy system, you know the feeling:
… Every release is a risk.
Manual regression testing takes days (or weeks).
End-to-end tests break if someone makes the smallest change.
And unit tests? Try covering the whole codebase before 2030.

So what do you do when:

• You can’t stop shipping features

• You need safety and fast feedback

• And your test automation strategy is going nowhere?

Join me for a live workshop on ATDD in Legacy Code

In this 2-hour session, I’ll walk you through a practical and safe roadmap for introducing Acceptance Test-Driven Development into a legacy system — without pausing feature work or risking production.

💡 You’ll learn:

✅ How to eliminate manual QA by replacing it with automated system-level acceptance tests
✅ How to introduce ATDD safely while keeping up with feature delivery
✅ Why acceptance tests give you the highest ROI (much faster than unit or E2E tests)
✅ How to align your PO, developers, and QA around executable specifications that reduce rework and waste

🎯 Who is this for?

This session is for technical leaders and senior engineers who need to get things moving — now.

• CTOs & Engineering Managers who want to reduce QA costs without risking the product roadmap

• Team Leads & Senior Developers who need to position ATDD internally and handle counterarguments like:

“Why not just write more E2E tests?”
“We don’t have time for unit tests”

🎁 Free for Paid Optivem Journal Members

If you're already a paid member, this workshop is included for free.
👉 Click here to claim your 100% discount

Not a member yet? You can upgrade now and get immediate access to the session (plus replays and future events).
👉 Upgrade to Paid Membership

📅 When:

Wednesday, 6th Aug, 5-7pm CEST

Replay will be available to Optivem Journal Paid members.

👉 Spots are limited – Sign up here

Let’s stop wasting time on flaky tests and manual QA.
Let’s build something better — even in legacy code.

See you there,
Valentina
Technical Coach, Optivem

Subscribe now

Adapting to External System API Changes is risky without tests

Suppose that the External System API has changed. But we don’t have any External System Contract Tests. It means we’d find out our System is broken when users start reporting Production Bugs. We’d then have to wait for the slow-running Manual QA Testing to reproduce those bugs, and then discover - it’s due to External Systems!

So now that we have to adapt our System, we’re faced with additional challenges - our Legacy Project doesn’t have tests, and the business logic is often coupled to communication with External Systems. Thus, when an External System changes its API, if we try to adapt to the updated External System API, we may need to make broad changes, and it’s very risky… when there’s no tests.

How to use ATDD for handling External System API Changes

When implementing User Stories, applying ATDD involves writing a failing Acceptance Test to specify the behavior, implementing the behavior, and verifying that the Acceptance Test passes. A similar process happened with implementing Bug fixes, since both User Stories & Bugs are concerned with behavioral changes.

But how do we handle structural changes - such as External System API changes, e.g. there might be a change in their URL routes, or changes to the data input/output structures. It’s just a structural change, not a behavioral change.

How ATDD differs:

• For behavioral changes, applying ATDD means that we start with writing a failing Acceptance Test, then we try to implement the System to make the test pass.

• Regarding structural changes (External System API Change), we do NOT write an Acceptance Test. Instead, we update the External System API Driver to reflect the updated API, which causes multiple Acceptance Tests to fail. Then we try to “adapt“ our System so that the Acceptance Tests can pass again.

Let’s illustrate the ATDD cycle for External System API Change Tasks:

Here are the steps to introduce ATDD for External System Changes in Legacy Code. I’ll provide you with step-by-step guidance on how to handle External System Changes in your GitHub Sandbox Project. ⬇️⬇️⬇️

Read more

Subscribe now

API Redesign is risky without tests

API Redesign (in the case of public-facing APIs) is risky because it could cause regression bugs.

How to use ATDD for API Redesign

When implementing User Stories, applying ATDD involved writing a failing Acceptance Test to specify the behavior, implementing the behavior, and verifying that the Acceptance Test passes. A similar process happened with implementing Bug fixes, since both User Stories & Bugs are concerned with behavioral changes.

But how do we handle structural changes - such as API Redesign? Example, for splitting one field (e.g. “name“) into two fields (“first name“ and “last name“). It’s just a structural change, not a behavioral change.

How ATDD differs:

• For behavioral changes, applying ATDD meant that we start with writing a failing Acceptance Test.

• Regarding structural changes (System API Redesign), we do NOT write an Acceptance Test. Instead, we update the System API Driver to reflect the updated API, which causes multiple Acceptance Tests to fail.

Let’s illustrate the ATDD cycle for System API Redesign Tasks:

Here are the steps to introduce ATDD for API Redesign in Legacy Code. I’ll provide you with step-by-step guidance on how to introduce ATDD in your GitHub Sandbox Project. ⬇️⬇️⬇️

Read more

Subscribe now

UX/UI Redesign is risky without tests

UX/UI Redesign is more than just changing colors and fonts, more than just moving elements around. It can involve changing the identifiers and types of UI elements, moving elements across screens, or splitting one UI element into multiple UI elements. These are UI Structural Changes that can easily cause Regression Bugs.

How to use ATDD for UX/UI Redesign

When implementing User Stories, applying ATDD involved writing a failing Acceptance Test to specify the behavior, implementing the behavior, and verifying that the Acceptance Test passes. This is similar to implementing Bug fixes, since both User Stories & Bugs are concerned with behavioral changes.

But how do we handle structural changes - such as UX/UI Redesign? This kind of change affects how the UI looks like but, from end user perspective, the functionality is the same, just the way it’s presented on the UI is different (e.g. instead of inputting data on one screen we’d input it over 5 screens with a “Next“ button separator; or instead of inputting the full name on one field it would be inputted over two fields - first name & last name). It’s just a structural change, not a behavioral change.

How ATDD differs:

• For behavioral changes, when applying ATDD we start with writing a failing Acceptance Test.

• Regarding structural changes (System UI Redesign), we do NOT write an Acceptance Test. Instead, we update the System UI Driver to reflect the updated UI, and that in turn causes multiple Acceptance Tests to fail.

Let’s illustrate the ATDD cycle for System UI Redesign Tasks:

Here are the steps to introduce ATDD for System UI Redesign in Legacy Code. I’ll provide you with step-by-step guidance on how to apply ATDD in your GitHub Sandbox Project. ⬇️⬇️⬇️

Read more

Subscribe now

Problem #1: The bug isn’t solved?!

Sometimes when Developers get a Bug ticket, they immediately jump to the “solution“ (they immediately think of the bug fix in their mind), open up the code straightaway, make the changes, and as soon as possible, hand it over to QA Engineers. But then the QA Engineer tests the fix, and says that the bug wasn’t actually solved. Or it may even pass the QA testing, but the User complains that the bug wasn’t fixed.

Why? The developer hadn’t actually reproduced the bug BEFORE attempting to fix the bug.

Problem #2: The bugs keep re-reoccurring!

Many teams face the challenge of fixing a bug, having it tested by QA, and having the fix deployed to Production… But then, some months later, the same bug appears in the system! What’s even worse is that the bug keeps coming back, it’s unstoppable.

Why? The bug fix was only verified manually, with no automated verification. This means that when we introduce the bug again, we have no idea.

Solution: Use ATDD for reliable Bug Fixing

By applying ATDD to fix bugs, it helps us solve problems:

• Through the Bug report, we translate the expected behavior into a failing Acceptance Test, to prove that we’ve reproduced the bug

• Then, when we implement the bug fix, and the Acceptance Test passes, we can be sure that we’ve fixed the bug

• Lastly, the Acceptance Test remains in our Test Suite, so if the bug accidentally ever occurs again, it will be caught by the Acceptance Test (thus, the bug won’t reach the QA Engineer, and won’t reach the End User)

Here are the steps to introduce ATDD for Bug Fixes in Legacy Code. I’ll provide you with step-by-step guidance on how to introduce ATDD in your GitHub Sandbox Project. ⬇️⬇️⬇️

Read more

Subscribe now

4000 Acceptance Tests in < 1h

Alessandro Fardin, Software Engineering Team Lead at Carlo Gavazzi Controls, Italy, has shared his success story of using Acceptance Tests on Substack discussion.

“… some years ago we start a Continuous Delivery transformation journey.

Our application is a iiot gateway Linux embedded device

We change lots of things in our behavior, we had only manual tests then we started to add automatic acceptance tests, now we have a suite of 4000 tests that run in parallel in about 30 minutes.”

He summarized the transformation:

“from late phase manual test --> frequent and early manual test

from manual test --> continuous automatic accepting test

continuous automatic accepting test (14 hours)---> fast parallel accepting test (40 minutes)”

Lessons Learnt #1

It’s ok to start with manual testing. Indeed, that’s where most companies are.

Here’s the transition process:

1. Most companies start with late phase manual testing, typically testing in preparation for a production release. This might delay the release by several months.

2. The first point of improvement is to switch to earlier and more frequent manual testing, rather than doing it all at the end.

3. We’ll then start feeling the pain of manual testing, and realize it’s too expensive to do it earlier and more frequently. So then we need to replace Manual QA testing by automated Acceptance Testing.

4. Lastly, we want to reduce the runtime of automated Acceptance Testing. By parallelizing these tests, it goes a long way forward.

Acceptance Tests in Continuous Delivery

Acceptance Tests are a crucial part of Continuous Delivery, and they have the biggest impact, compared to other lower-level tests.

Many companies make the mistake - let’s just write Unit Tests, get 80% Code Coverage… but yet Acceptance Testing is still done manually - by the QA Engineers.

Fortunately, Alessandro’s team took the right approach, starting top down with Acceptance Tests as a replacement of Manual Regression Testing. This has the highest visible impact - it has the biggest impact in reducing the delivery cycle length AND also reducing production bugs.

Acceptance Testing is crucial in reducing the overall system-level feedback loop and removing the waste of Manual Regression Testing.

Alessandro Fardin shared his story (here's the version translated to English):

What are the results?

Some key ingredients included:

• Pipeline

• Acceptance Tests

See the Carlo Gavazzi Controls Black Belt Case Study.

The result was a 43% reduction in defects found in production. The feedback cycle was reduced from several months to 40 mins, and deployment from 6 months to 1 month. Developers also reduced time spent on bug fixing by 30%.

Source: Carlo Gavazzi Controls Black Belt Case Study

Lessons Learnt #2

If you’re going to start automated tests, starting with Acceptance Tests. They are the tests with highest visible ROI - testing the system from the End User perspective, testing User Story Acceptance Criteria and it has a direct impact on Bug Tickets.

After you do this, then sure, look at lower level tests.

That’s the same sequence I follow as part of the TDD in Legacy Code series. We start with the System Level first (Acceptance Testing & ATDD) before we go onto apply TDD at the lower levels (Component Testing & CTDD, Unit Testing & TDD).

Leave a comment

Share your success story

I’d like to feature TDD success stories in future editions. To share your story, write a comment below. 💪

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.

Subscribe now

How to handle implementing External System DSL?

Previously, we covered the core process of applying ATDD for User Stories. However, in that core process, we assumed that the DSL already exists.

However, what happens when the External System DSL doesn’t exist? We need to implement the External System DSL and the External System Driver before going towards System implementation.

Here are the steps to introduce ATDD for new User Stories in Legacy Code, in the case where the External System DSL does not exist. I’ll provide you with step-by-step guidance on how to introduce ATDD in your GitHub Sandbox Project. ⬇️⬇️⬇️

Read more

Subscribe now

How to handle implementing System DSL?

Previously, we covered the core process of applying ATDD for User Stories, where we assumed that the DSL exists.

However, what if the System DSL doesn’t exist? We need to implement the System DSL and the System Driver before going towards System implementation.

Here are the steps to introduce ATDD for new User Stories in Legacy Code, where where the System DSL does not exist. I’ll provide you with step-by-step guidance on how to introduce ATDD in your GitHub Sandbox Project. ⬇️⬇️⬇️

Read more

Subscribe now

Writing Acceptance Tests at the end? Chaos.

When working in Legacy Code, the team was used to a siloed way of working, where developers do coding, and then QA does testing. So they see testing as something that comes at the end.

This means, even after learning automated Acceptance Testing, we might be drawn to old habits - writing those Acceptance Tests at the end.

But what happens when we write Acceptance Tests at the end?

• We may discover that we actually don’t understand the Acceptance Criteria, that the Acceptance Criteria wasn’t written in a testable way

• We may discover that the PO had one interpretation of an Acceptance Criteria, Developers had another interpretation, and QA Engineer had yet another interpretation

Writing Acceptance Tests at the start? Alignment.

So how do we solve the problem of misinterpretations and misunderstandings?

Start by eliminating silos. Even though the PO has ownership over Acceptance Criteria, the whole team should be involved in Backlog Refinement, so that the Acceptance Criteria is written in a testable way.

Since we have testable Acceptance Criteria, we can convert it to Acceptance Tests before starting implementation. For new User Stories, we should be applying ATDD.

How to practice ATDD on User Stories

After refinement, a User Story should have testable Acceptance Criteria. We can incrementally take each Acceptance Criteria, one by one: convert the Acceptance Criteria into an Acceptance Test, implement code changes to the System so that the Acceptance Test is passing (indeed, all the Acceptance Tests should pass), and finally refactor if needed (ensuring that all the Acceptance Tests are still passing).

Here are the steps to introduce ATDD for new User Stories in Legacy Code. I’ll provide you with step-by-step guidance on how to introduce ATDD in your GitHub Sandbox Project. ⬇️⬇️⬇️

Read more