End-to-End Test Suite

Write stable end-to-end tests for the flows that matter: resilient selectors, real waits, isolated data, and no test that tests everything.

Write end-to-end tests for this application.

Framework: [PLAYWRIGHT / CYPRESS / SELENIUM] and language: [TS / PYTHON / OTHER]
The app and its critical user journeys: [THE 3-7 FLOWS THAT LOSING WOULD ACTUALLY HURT]
Relevant markup or components:
"""
[PASTE THE PAGES, COMPONENTS, OR SELECTORS INVOLVED]
"""
Auth: [HOW USERS LOG IN, AND WHETHER YOU CAN SEED A SESSION DIRECTLY]
Test data: [HOW TO CREATE AND CLEAN UP DATA, AND WHETHER THE ENVIRONMENT IS SHARED]
Known slow or async parts: [WHAT LOADS LATE, WHAT POLLS, WHAT ANIMATES]

Requirements:
- **Cover journeys, not pages.** One test per user journey, ending in an assertion about a real outcome (the record exists, the email was queued, the balance changed), not just that a success message rendered.
- **Selectors in this order of preference**: role and accessible name, then visible label text, then an explicit test id. Never CSS classes or DOM structure. If the markup does not support this, say which test ids to add rather than writing a brittle selector.
- **Wait on conditions, never on time.** No fixed sleeps. Wait for the element state, the network response, or the assertion to become true. Where the framework's auto-waiting is enough, rely on it rather than adding redundant waits.
- **Isolate data.** Each test creates what it needs with a unique identifier and cleans up after itself, and tests must pass in any order and in parallel. Say what to do about anything genuinely shared.
- **Log in once** through the API or a stored session where possible, rather than driving the login form in every test. Keep exactly one test that exercises the real login form.
- **Assert failure paths too**: at least one test per journey covering the realistic error (validation rejected, payment declined, permission denied).
- Keep each test readable as a description of what a user does. Push setup into helpers, and keep the assertions in the test body.

Also produce:
1. **What not to test here.** The cases better covered by unit or integration tests, and why. An end-to-end suite that tries to cover everything becomes the slow, distrusted suite people skip.
2. **The debugging setup**: traces, screenshots, video on failure, and how to reproduce a CI failure locally.
3. **Expected runtime** and what to run on every commit versus nightly.

Rules: derive selectors from the markup I pasted. Do not invent element structure. Where the markup lacks an accessible name, flag the accessibility gap; fixing it usually improves both the app and the test.

How to use

End-to-end suites die from flakiness, and flakiness comes overwhelmingly from two habits: selectors coupled to markup and sleeps standing in for waits. Both are ruled out here as requirements rather than suggestions. Section 1 is the discipline that keeps the suite fast enough to stay trusted, since the cost of an end-to-end test is paid on every run forever, and the same coverage is often available a layer down for a fraction of the runtime.

More coding prompts

Write the commit message for this change.

Diff:
"""
[PASTE THE STAGED DIFF]
"""

Why I made this change: [THE REASON, THE TICKET, THE BUG REPORT, or "you infer it"]
Convention: [Conventional Commits / this repo's existing style, pasted below / plain]
Recent commits from this repo, to match style:
"""
[PASTE 5-10 RECENT COMMIT SUBJECT LIN

Commit Message

Write a commit message that explains why the change was made, in Conventional Commits format, split into separate commits when needed.

Codingbeginner

Help me recover from a git mistake without making it worse.

What I was trying to do: [THE GOAL]
What I ran: [THE EXACT COMMANDS, IN ORDER]
What happened instead: [THE OUTPUT OR THE STATE NOW]
Has this been pushed or shared: [YES/NO, and to which branch and whether anyone else has pulled]
Uncommitted work I cannot lose: [WHAT AND WHERE, o

Undo a Git Mistake

Recover from a bad commit, force push, wrong branch, or lost work with a reversible plan and the exact commands, explained before you run them.

Codingintermediate

Handler code, routes, and models:
"""
[PASTE THE ROUTE DEFINITIONS, HANDLERS, REQUEST AND RESPONSE TYPES, VALIDATION SCHEMAS, AND MIDDLEWARE]
"""

Generate an OpenAPI 3.1 specification from the code above.

API name, version, and base URL: [DETAILS]
Auth scheme: [BEARER JWT / API KEY / OAUTH / SESSION COOKIE, and where it is enforced]
Con

OpenAPI Spec From Code

Generate an accurate OpenAPI 3.1 spec from handler code, including error responses and auth, with gaps flagged instead of invented.