Phase 5 / Ep 22 | Building an E2E Headless Testing Automation Workflow

3 MIN READ | UPDATED: 2026-05-15

Now that all the core backend business logic is running smoothly, it's time to render the interface on the screen. Writing UI is an area where Large Language Models excel, but it's also where they can easily produce code that looks good but is functionally flawed.

It might generate a very nice-looking "Sync Calendar" button for you, but that button might be completely unresponsive when clicked. That's why we need to bring out the big guns: end-to-end (E2E) headless browser testing.

1. Establish a Dedicated Workflow

Set the rules in .agents/workflows/e2e-testing.md:

---
description: E2E test execution and development flow
---
1. Tasks involving browser clickstreams must be verified using Playwright.
2. When selecting buttons, to counteract Tailwind's ugly, dynamic class names, you **must first add a clear `data-testid` attribute** to the component at the `app/` level. Selecting elements based on relative paths like `div > div > button` is strictly forbidden.
3. Please start the project on a dedicated, isolated port for testing (to prevent conflicts).

2. Preventing Test Environment Failures

Why is the third rule necessary? Many developers using crude AI agents let them run tests automatically. As a result, the AI connects to the production network locally and wipes the database while running tests.

By establishing this workflow, we prime the Agent with a core directive before it executes any instructions: whenever a task involves browser flow operations, it must adhere to isolation and reset mechanisms. Testing is supposed to put out fires, not burn down the entire base.