Test a support widget creating a ticket

The flow under test

The ticket has to carry five attributes correctly, and the two that are selected rather than typed decide how fast anyone looks at it.

• Required fields are enforced - an empty submit produces errors on email, subject and description.
• The ticket exists - numbered 4413.
• The routing attributes - a priority of High and a type of Problem, which drive queue and SLA.
• The requester - the email, which is the only way anyone can reply.

Priority and type are the fields worth asserting hardest. They are dropdowns nobody checks, they default silently, and a high priority ticket filed as a normal question waits days instead of minutes.

The test file

The launcher is clicked first and the form asserted by its heading, so a widget that fails to open is distinguishable from one whose form is broken.

---
mode: testing
url: https://my-testing-repo-main.vercel.app/zendesk-clone-app/widget?reset=true
max_steps: 45
tags: [zendesk, support, tickets]
---

# Zendisk 30.1: Widget ticket

Catalog objective: submit a ticket through the web widget.
Key assertion: the ticket is created with the correct fields.

## Open the widget
Click the "💬 Help" launcher and verify a "How can we help?" form appears.

## Verify the required fields are enforced
Click "Submit" with the form empty and verify inline errors appear on the email, subject and description fields.

## Fill in the request
Type "sam@riverfield.test" into "Your email", "Export never finishes" into "Subject", "The CSV export spins forever on large date ranges." into the description, select "High" in "Priority" and "Problem" in "Type", then click "Submit".

## Verify the ticket was created with those fields
Verify a green banner titled "Ticket received" names ticket "#4413", and the summary shows "Subject" of "Export never finishes", "Priority" of "High", "Type" of "Problem", "Status" of "New" and "Requester" of "sam@riverfield.test".

The status of New is asserted alongside the rest, since a ticket created in any other state may bypass the queue it was supposed to enter.

Step by step coverage

A launcher, a refusal, a submission and the ticket.

Asserting all three inline errors rather than one is what proves each field validates independently rather than the form simply refusing to submit.

Running it

kane-cli testmd run tests/zendesk/widget-ticket_test.md

Add a submission from a signed-in user, since the requester should be filled automatically and an authenticated ticket attributed to the wrong account is worse than an anonymous one.

The support widget sits on every page, so a regression affects the whole site. Running Kane CLI in CI covers catching it, and exact string assertions covers pinning the validation messages.