Optivem Journal

Optivem Journal

ATDD

Refactoring Should NOT Touch Your Acceptance Tests

A “refactor” PR that changes the acceptance test or the DSL isn't a refactor — it's a behavioral change

Valentina Jemuović's avatar
Valentina Jemuović
Sep 03, 2026
∙ Paid

📅 Join our next live course: ATDD, Clean Architecture, Pipelines
Ealy bird: €100 off with code EARLYBIRD100


You open a PR labelled:

“API redesign — no behavior change”

Looks fine.

Merged.

The one-line acceptance test change goes unnoticed.

Six months later, a regression bug slips through.

The acceptance test that was supposed to catch it didn’t.

Why?

Because the test was quietly changed at the same time as the code.

That’s the problem.

If the behavior didn't change, the acceptance test shouldn't need to change.

The driver should handle it.

✅The test stays the same — the driver changes

Look at PlaceOrderPositiveTest.java in the shop’s system-test module:

@TestTemplate
@Channel({ChannelType.UI, ChannelType.API})
void shouldCalculateBasePriceAsProductOfUnitPriceAndQuantity() {
    scenario
            .given().product()
                .withUnitPrice(20.00)
            .when().placeOrder()
                .withQuantity(5)
            .then().shouldSucceed()
            .and().order()
                .hasBasePrice(100.00);
}

This test has no idea whether the order is placed by POST /api/orders or POST /api/purchases.

It has no idea whether the UI’s place-order button is selected by [aria-label="Place Order"] or by some new CSS class.

It also has no idea whether the ERP returns the product’s price as price or unitPrice.

This post is for paid subscribers

Already a paid subscriber? Sign in
© 2026 Valentina Jemuović, Optivem · Privacy ∙ Terms ∙ Collection notice
Start your SubstackGet the app
Substack is the home for great culture