Solution: Test a Complex Form Workflow
Tests verify user-visible behavior only. A parent-owned draft preserves input across steps, validation blocks progress with accessible field-linked alerts, and submission is transactional with `useActionState`, `useOptimistic`, and `useTransition` to show an immediate pending receipt and keep the UI responsive.
We'll cover the following...
Here’s the implementation for the complex form workflow with an explicit wizard owner that centralizes draft, step, and error state so every step transition is a pure view change, not a data reset. Validation is treated as part of the commit cycle: when the user attempts to advance with invalid fields, errors render next to inputs, each input is marked with aria-invalid, each message is referenced by aria-describedby, and focus moves once to the first invalid control, so the next interaction is predictable for keyboard and assistive technology users. Submission is handled transactionally by locking to a single in-flight attempt, announcing “Submitting…” through a live region, and rendering an optimistic receipt that either becomes confirmed on success or rolls back on failure, exposing a retry path without collapsing the UI into global loading states.
Testability remains stable because the manual harness asserts only observable behavior and semantic output: step headings, button enabled/disabled states, live-region messages, receipt state, and aXe’s structural violations. Correctness converges through scoped updates, only the receipt and status change during submission, and the rest of the wizard remains committed and calm as validation, transitions, optimistic UI, and retry flows overlap.