E2E Tests in Plain English: A Robot That Tests Your Site for You

What an E2E Test Is, in Plain English

Imagine you just assembled a wardrobe from IKEA. It’s standing, the doors are on, looks great. But before you load your favorite dinner set into it - you’re going to tug on every shelf and check that no drawer falls out, right? Of course. Otherwise, on day three, the shelf full of dishes crashes down right onto the cat.

It’s exactly the same with a website. You (well, your agent) put together a landing page or an app. It kind of works. But “kind of” isn’t a check - it’s a hope. Someone has to open the site like a real visitor, push the buttons, fill in the forms, and make sure nothing fell apart.

That “someone” can be a patient human who clicks the same thing a hundred times and quietly hates their job. Or it can be an E2E test E2E (end-to-end) is a test that checks the whole user journey from start to finish: from landing on the site to getting the result, as if a real person were sitting at the computer. - a tiny robot you explained the task to once, and it repeats it flawlessly, for free, without burnout, a thousand times in a row.

Why a Vibecoder Needs E2E Tests

You’re a vibecoder. You don’t write tests by hand. But if you understand why they’re needed and how to ask your agent to make them, you get four things at once:

• you catch breakage before the client sees it - not from an angry message at two in the morning;
• you keep editing the site with peace of mind: the robot tells you right away exactly what you just broke;
• you save hours of manual re-checking in the spirit of “is everything still working?”;
• you look like a pro. The phrase “I have tests” sounds solid even to a client.

Without tests, every new feature is a lottery. You fix one thing, secretly break another, and find out by accident. With E2E tests, you’ve got a watchman who walks the whole site in seconds.

How Claude Writes E2E Tests: a Robot in a Real Browser

The main tool here is Playwright Playwright is a free tool from Microsoft that launches a real browser (Chrome, Firefox, Safari) and controls it from code: opens pages, clicks, types, checks the result. . It’s the robot’s hands and eyes. It opens a real browser, visits your site, and behaves like a live user. Not a simulation, not an emulation - a real Chrome driven by code.

A Test Is a User Scenario, Not Code

A good E2E test reads almost like instructions for your grandma: “open the page, type a word into search, check that results showed up.” You describe a person’s journey, not the guts of the code. That’s the whole secret.

Here’s what such a test looks like. You don’t need to write it by hand - your agent will do that - but it’s useful to recognize one on sight:

test('search finds products', async ({ page }) => {
  await page.goto('/items')          // opened the page
  await searchInput.fill('test')      // typed into search
  expect(count).toBeGreaterThan(0)    // checked: something was found
})

Read it out loud, and it’s clear what’s happening. That’s how it should be.

Hook Onto data-testid, Not Text and Color

The robot needs some way to find a button on the page. You could hook onto the text (“the button labeled Buy”) - but that’s fragile. Change the text to “Order” and the test falls over out of nowhere, even though the site works perfectly.

That’s why pros pin an invisible label on elements - data-testid data-testid is a special invisible tag on a page element (for example data-testid='buy'). The user never sees it, but the test uses it to reliably find the right button, even if the text or color changes. . It’s like a luggage tag on a suitcase. You can repaint the suitcase hot pink, but the tag with the number stays put - and the robot always finds what it needs.

Wait for an Event, Not “Just Wait”

A site doesn’t load instantly. The robot often rushes to a button before it appears - and trips face-first into empty space. The rookie reflex here is always the same: “let it wait 5 seconds.” That’s the worst possible call. On a fast connection, you just gifted the test 5 seconds of idling for nothing. And on a slow one, those 5 seconds weren’t enough, and the test failed anyway.

The right way? Wait for a specific event: “wait until the data loads,” “wait until the button becomes visible.” The robot waits exactly as long as it needs, and not a second more.

A Good E2E Test vs. a Bad One: What’s the Difference

A Real-Life Example: How an Animation Broke the Checkout

You built a little online shop. Everything works. A week later, at your request, the agent added a slick animation to the “Buy” button. You were pleased, deployed it, and went to bed with a clear conscience.

In the morning - a message: “I can’t place an order.” Turns out the animation slid on top of the button, and it became physically impossible to click. You never found out. Why? Because you didn’t re-check the checkout yourself - why would you, you only touched the animation.

Now imagine the same thing with E2E tests. After the edit, the robot would have walked the path itself - “picked a product, clicked Buy, filled in the form, saw Thanks for your order” - tripped on the invisible button, taken a screenshot, and screamed “BROKEN” before the deploy. No ruined morning and no lost client.

To get a robot like that, you don’t need to write anything yourself. You just need to ask the agent the right way:

Write E2E tests in Playwright for my site. Cover the main real-user scenarios:

Landing on the homepage and checking that the page opened.
The full checkout flow: pick a product, click Buy, fill in the form, see the confirmation.
Site search: enter a word and check that results appeared.
Important rules:

Hook onto data-testid, not text or color. Where there isn’t one - add it.
Don’t use fixed pauses. Wait for specific events: data loading, an element appearing.
On failure, take a screenshot so it’s clear what broke.
Explain in plain English how I run these tests with a single command.

Where You Can’t Skip E2E Tests, and Where You Can Relax

There are places where a breakage costs not nerves but real money. There, tests aren’t a luxury - they’re a duty. And there are zones where you can exhale and not overdo it. Here’s the line:

Run Tests Automatically Before Every Deploy

Writing the tests once isn’t enough. They’re treacherously easy to forget about. So pros set things up so the tests run on their own every time the site updates. This is called CI/CD - an auto-run pipeline. The robot checks everything before publishing, and if even one thing is glowing red, the site simply doesn’t ship until you fix it.

You don’t need to set this up by hand. Just ask the agent: “set up auto-running E2E tests before every deploy.” That’s it. That’s how tests go from “I’ll check it someday” to a permanent safety net that never sleeps.

Common Beginner Mistakes in E2E Tests

• Not writing tests at all. “I checked it” works right up until the first edit that quietly breaks everything.
• Testing the code instead of the user. A test should walk a real person’s path, not poke around in the internals.
• Hooking onto text and color. Change the label - the test fails. Use data-testid.
• Cramming in “wait 5 seconds” pauses. That’s a straight road to flaky tests nobody trusts.
• Ignoring a failing test. A red test is a signal, not a nuisance. Fix it, don’t switch it off “so it stops bugging me.”
• Running money tests on the live site. Payment tests run only on a test copy.