Log in to QA Shop with Playwright — your end-to-end auth recipe

This recipe is the smallest end-to-end Playwright test that signs a seeded customer into QA Shop and proves the session is live.

It walks the public login surface — load the page, fill credentials with accessible-label selectors, click submit, and assert the authenticated-only header menu after the redirect. Run it on your laptop in about five seconds.

It is the canonical first test to write whenever you need to drive a real session into your suite, and it is the foundation that every authenticated QA Shop recipe (checkout, account settings, order history) builds on top of.

You need a project with @playwright/test installed, a Playwright config that points at QA Shop, and a seeded customer to log in as.

Save this file as tests/recipes/playwright/login-flow-test.spec.ts and run it with npx playwright test --grep login-flow-test.

// tests/recipes/playwright/login-flow-test.spec.ts
import { test, expect } from "@playwright/test";
 
test("a seeded customer can log in and land authenticated", async ({ page }) => {
  const email = process.env.RECIPE_AUTH_EMAIL;
  const password = process.env.RECIPE_AUTH_PASSWORD;
 
  if (!email || !password) {
    throw new Error(
      "RECIPE_AUTH_EMAIL and RECIPE_AUTH_PASSWORD must be set. " +
        "See .env.example. In CI these come from GitHub repo secrets; " +
        "locally they come from your .env.local.",
    );
  }
 
  // 1. Land on the login page. The visible heading is "Welcome back!" but the
  //    submit button reads "Log in" — the button is the stable on-page anchor.
  await page.goto("/auth/login");
  const submitBtn = page.getByRole("button", { name: /log ?in/i });
  await expect(submitBtn).toBeVisible();
 
  // 2. Fill the credentials via accessible-label selectors. QA Shop randomizes
  //    auth-form input names as a honeypot defense, so a11y selectors are the
  //    only stable surface — never `data-testid` here.
  await page.getByLabel("Email", { exact: true }).fill(email);
  await page.getByLabel("Password", { exact: true }).fill(password);
 
  // 3. Submit. Turnstile is not on /auth/login (scoped to principal register
  //    + forgot-password only), so the button is enabled on render.
  await submitBtn.click();
 
  // 4. The post-login redirect lands somewhere outside /auth/*.
  await page.waitForURL((url) => !url.pathname.startsWith("/auth/"));
 
  // 5. The header user menu only renders for authenticated sessions.
  await expect(page.getByTestId("header-user-menu")).toBeVisible();
});

The first navigation to /auth/login is plain page.goto — no readiness flag yet.

The first locator is the submit button, captured with getByRole("button", { name: /log ?in/i }). The visible heading on the page is Welcome back!, not Log in, so anchoring on the button (rendered text Log in) is the right call: it is the same element the user will eventually click, and asserting it is visible doubles as a "form is mounted and ready" readiness check.

Filling the email and password uses page.getByLabel("Email", { exact: true }) and page.getByLabel("Password", { exact: true }). Both inputs preserve their aria-label, <label>, and autocomplete="email" / "current-password" attributes regardless of name randomization, so password managers, screen readers, and the recipe all share one selector contract. The exact: true option is the small but load-bearing detail on the password line — the password input ships with a sibling aria-label="Show password" toggle button, and without exact the locator matches both elements (strict-mode violation).

The submit click runs immediately after filling the form. QA Shop scopes Cloudflare Turnstile to principal-account register + forgot-password only, so /auth/login renders with an enabled submit button — no token wait, no widget mount, no headless-browser flake. The four remaining defenses on the login path (rate-limit, honeypot, IP block-list, and the abuse-block check in proxy.ts) handle credential stuffing without adding interactive friction.

The post-click page.waitForURL((url) => !url.pathname.startsWith("/auth/")) is a function-form URL predicate¹. Function form is the right idiom here because the redirect target is variable: a guest who navigated to /auth/login directly lands on /, but a guest sent to /auth/login?redirect=%2Fcheckout lands on /checkout. The predicate accepts both without needing a brittle regex listing every legal landing page.

The final assertion is page.getByTestId("header-user-menu"). The header user menu is one of the few public testids QA Shop guarantees to be stable: it only renders for authenticated sessions, it lives in the global header on every route, and the testid is plain (no UUID, no order_number) because it is a UI affordance rather than a data row. It is the canonical "session is live" signal across the entire app.

Three obvious variants build on this skeleton.

A fourth variant worth scripting eventually is the OAuth path — the login form ships with a GitHub OAuth button alongside the credential form. That spec needs a stubbed identity provider and is a noticeable jump in setup cost, but it is the right next test once the credential flow is solid.

Related

For the full testid catalog and the security model behind the honeypot naming inversion, see the QA Shop testing guide. For the broader checkout flow this recipe unlocks, see Add to cart and reach checkout.

The Selenium, Cypress, and WebdriverIO login counterparts are coming soon — placeholder slugs are /recipes/selenium/login-flow-test, /recipes/cypress/login-flow-test, and /recipes/webdriverio/login-flow-test. The /recipes index lists them as they ship.

Last verified: May 3, 2026