ryanlee

Posted on Sep 21

React Signup Tests Need Intent, Not Just Clicks

#webdev #javascript #react #testing

Signup tests often look healthy while proving very little. A test clicks the submit button, waits for a selector, and turns green. Then a small copy change, a slower email provider, or a duplicate request exposes that the test was following the UI instead of checking what a user intended.

For React teams, the useful shift is simple: test the intent behind a signup, not just the clicks used to reach it. A good test should answer questions like:

Did a person submit a complete and valid form?
Was the verification message requested exactly once?
Does the UI show the right state while the message is pending?
Is the confirmation link connected to the same signup attempt?

This approach makes JavaScript tests a little more boring, and that is a feature. Boring tests are easier to trust when a release is moving fast.

The click is not the user intent

Consider a signup form with an email field, password field, terms checkbox, and submit button. A click-only test may pass even when the button is accidentally enabled before the form is valid. It might also pass after a validation error because the assertion only checks that a request was made.

The user intent is more precise: “I submitted this email and password after accepting the terms, and I expect one verification attempt.” The test should express that contract directly.

This is especially important for email verification. Test data such as temp mailid or tem email can be useful as malformed input cases, but they should not be mixed into the happy path. Keep invalid syntax, duplicate accounts, and expired links as separate scenarios so each failure explains something.

Model the signup states first

Before reaching for another selector, write down the state transitions:

idle — the form is empty or incomplete.
ready — required fields are valid and terms are accepted.
submitting — one request is in flight and duplicate submits are blocked.
verification-pending — the account was created, but the email is not confirmed.
verified — the confirmation token is accepted.
error — the user can understand and recover from a failure.

The names do not need to become a large state machine library. They are a design tool for deciding what the test should observe. For example, submitting should be visible through an accessible status message or disabled action, while verification-pending should have a stable heading that does not depend on a layout class.

This small bit of structure make the happy path easier to scan during review.

The test are more durable when assertions describe these states rather than implementation details. A CSS class can change during a redesign; the user-facing status should not.

Build a small intent-aware fixture

A lightweight fixture can keep the test readable while making the request contract explicit:

export function buildSignupIntent(overrides = {}) {
  return {
    email: "case-42@example.test",
    password: "CorrectHorseBatteryStaple!42",
    acceptedTerms: true,
    ...overrides,
  };
}

test("shows verification pending after one valid signup", async ({ page }) => {
  const intent = buildSignupIntent();

  await page.getByLabel("Email").fill(intent.email);
  await page.getByLabel("Password").fill(intent.password);
  await page.getByLabel("Accept terms").check();
  await page.getByRole("button", { name: "Create account" }).click();

  await expect(page.getByRole("status")).toHaveText(
    "Check your email to verify your account"
  );
});

The fixture gives every test a clear subject. More importantly, it lets a negative case state its purpose:

const intent = buildSignupIntent({ acceptedTerms: false });

That is better than sprinkling one-off strings through five tests and trying to remember which values were intentional. The little factory also makes it easy to add a request spy and assert that a double click did not create two signup attempts.

The contract feel much clearer when the data has a name.

Assert outcomes at the right boundary

React tests become flaky when they wait for incidental timing. Avoid “wait 500 ms, then inspect the page.” Wait for an observable outcome instead: a response, a status role, a route change, or a message with a stable accessible name.

For the network boundary, assert the important parts of the request without coupling the test to irrelevant headers:

const signupRequest = page.waitForRequest((request) =>
  request.method() === "POST" && request.url().endsWith("/api/signup")
);

await page.getByRole("button", { name: "Create account" }).click();

const request = await signupRequest;
expect(request.postDataJSON()).toMatchObject({
  email: "case-42@example.test",
});

Then verify the UI result separately. This separation tells you whether a failure is in form behavior, the API contract, or rendering. The distinction save time when CI turns red.

For more context on making browser assertions repeatable, these stable Playwright baselines are a useful companion. If the backend can receive a retry, pair the frontend assertion with idempotent API retries so the product contract is tested on both sides.

Keep parallel runs isolated

Parallel CI is where weak signup fixtures usually break. If every worker uses test@example.com, one test can consume another test's verification message or collide with an existing account.

Generate an identifier from the test scope, not from the current clock alone. A worker index plus a unique test ID is enough for many suites:

export function emailForTest(workerIndex, testId) {
  return `signup-${workerIndex}-${testId}@example.test`;
}

The inbox or mock transport should be disposable for the run, and cleanup should happen even when the test fails. Never reuse a real customer address just because it makes the first local run convenient. It makes debugging noisey and can leak test mail into a personal inbox.

Also decide what happens when the verification message is delayed. A bounded retry around message retrieval is reasonable; an unbounded retry hides product bugs. Document the timeout with the fixture, so the next developer doesnt have to guess why a test waits two minutes.

A practical checklist

Before merging a signup flow, check:

The test names the user intent, not just the button it clicks.
Valid and invalid email syntax are separate scenarios.
submitting blocks duplicate requests and has an observable status.
The verification fixture is isolated per worker and test.
Assertions use accessible roles, request contracts, or stable outcomes.
Email retrieval has a bounded timeout and cleanup path.
API retries cannot create duplicate accounts or duplicate verification work.
A failure points to the form, transport, backend, or UI boundary.

It’s tempting to add more clicks when a signup test flakes. Start by asking what intent is missing instead. Once the test models the states and owns its email fixture, the suite gets faster to debug and much harder to fool.

DEV Community