browser-testing

Topics in the source

• Browser testing
• Scope and runtime preflight
• 1. Choose the journeys
• 2. Select elements the way a user identifies them
• 3. Never wait for time
• 4. Make each test own its data
• 5. Make failures diagnosable
• 6. Handle flakiness as a defect

Browser tests are the most expensive tests you own — slowest to run, most likely to break for reasons unrelated to your code, hardest to debug. That cost buys one thing nothing else does: proof that the pieces work together in a real browser. Spend that budget on a small number of journeys that must never break. A large E2E suite is not thorough; it is slow, flaky, and eventually ignored, and an ignored suite provides no safety while still consuming CI time. Rule of thumb: if a case can be covered below the UI, cover it there. E2E is for the wiring. Identify the target URL or local application, requested scenario, permitted account and data, and whether the task is exploration, form preparation, test generation, or debugging. Read the project's applicable agent instructions and existing test configuration first. Use the available, authorized browser integration; verify reachability and runtime support before claiming a test ran. For Playwright exploration, observed-first TypeScript generation, form preparation, or a local Node.js fallback, load references/playwright-workflows.md. It preserves these specialized workflows without requiring every browser test to use Playwright. Its he

This is an excerpt. Refer to the complete source and its current requirements.