Fluent DSL for Acceptance Tests: No More Typos, No More Try/Catch

Tests failed for all the wrong reasons—like typos

📅 Join me for Acceptance Testing (Live Training) on Wed 25th Feb (17:00 - 19:00 CET) (100% discount for Optivem Journal paid members)

---

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.