Testing
Dial the flow on the built-in phone, read the checks, and keep scenarios that must always pass.
The phone
Press P to show the phone, then Dial. Type replies the way a caller would. It is the same engine that serves real callers, so what you see is what they get, including pages on long screens and the message for a wrong choice.
Welcome to Example Bank 1. Check Balance 2. Exit
What the caller sees. The screen's message with its options numbered, exactly as the network will show it.
Reply like a caller. Type a number and send it, or use your keyboard.
Nothing real is touched. API calls get their test answers, so you can dial as often as you like.
API calls are answered from their test answers, so nothing reaches your real systems.
Checks
Checks in the dock lists what is wrong with the flow: a screen nothing leads to, an option that goes nowhere, a name used before it is set, a translation that is missing, YAML that cannot be read.
A flow with failing checks cannot be published.
Scenarios
A scenario is a call you want to keep working: the replies a caller types, in order, and where the call should end up.
- Replies go one per line, in the order a caller types them. Dialling in comes first on its own.
- A scenario can carry its own test answers, keyed by the call, such as
POST {{api_base}}/auth/verify. That is how you test the path for a wrong PIN as well as the right one.
Play a scenario to watch it on the phone. Scenarios also run before every publish: Publish stays locked while a scenario fails, so a change that breaks a path you care about cannot go out.
A good set to start with: the shortest successful call, one wrong answer at each input, and each way an API call can fail.