E2E Tests are dangerous

Many companies try to replace Manual QA by E2E Tests. The result? Disaster.

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

---

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”);