Why this flow is worth testing
A broken support form is a particularly damaging failure because it is self-concealing. Users who encounter a bug cannot file a support ticket to report it. Support queues go quiet not because everything is fine, but because the reporting mechanism has failed. The team typically does not find out until someone escalates through a different channel.
That makes it a strong candidate for early E2E coverage alongside login and checkout — not because it is revenue-critical, but because its failure has outsized impact on user trust and team visibility.
What tends to change in this flow
- Button labels — 'New Ticket' becomes 'Create Request' or similar
- Dialog behavior — slide-over instead of modal, or multi-step instead of single form
- Field names and placeholders — subject, body, category, priority
- Validation rules — required fields added or removed
- Post-submit state — redirect, inline confirmation, or toast notification
Testing modal interactions
The scenario below includes a dialog interaction step — waiting for the 'Create New Ticket' dialog before filling fields. This is important: without the wait, the test might attempt to fill fields before the dialog has finished rendering, producing a fragile test that works most of the time and fails occasionally for no obvious reason.
Assert handles this by resolving 'Wait for' steps as explicit conditions before proceeding. The scenario expresses the intent clearly; the execution layer handles the timing.
URL: https://app.example.com/support SCENARIO: Create a support ticket PROCESS: - Click "New Ticket" in "page-header" - Wait for "Create New Ticket" in dialog - Fill "email" with "hi@example.com" - Fill "subject" with "This is an E2E test" - Fill "body" with "Test email body" EXPECT: Create New Ticket dialog with subject and body filled
FAQ
Should the test submit the form and verify the ticket was created?
That depends on your testing environment. If you can submit support tickets in a test environment and clean them up reliably, a full submission test is valuable. If submitting creates real records or sends real notifications, testing up to the pre-submit state — with all fields filled and the form ready to submit — is a practical and still useful alternative.
How do you handle dialog-based forms reliably?
The key is always waiting for the dialog to be fully rendered before interacting with its contents. Assert's 'Wait for' step handles this explicitly. Skipping the wait step is the most common reason modal interaction tests become flaky.
Why is this a good example of what Assert is designed for?
Because it demonstrates the kind of readable, intent-level scenario that survives product changes. When the dialog title changes from 'Create New Ticket' to 'Open a Request', the update to this scenario is one word in one line — not a debugging session through selector code.
Put the workflow in your repo, not in a chat transcript
Assert is strongest when scenarios become durable project assets: readable Markdown in the repo, generated execution underneath, and result inspection in the dashboard.