Test, preview and debug
Test a workflow as a preview that changes nothing, test one step, or step through a run with breakpoints in the debugger.
You can try a workflow before it ever touches your store. The editor has three tools: Test for the whole workflow, Test this step for one step, and Debug to go through a run one step at a time. All three are free: they do not count against your plan, and they send no failure alert.
Preview or for real
Every test asks How to run:
- Preview (nothing is changed) - conditions and reads run for real. Steps that would change something only report what they would do.
- Run for real - every step runs: requests are sent and store data is changed.
Preview is the default. What that means per step:
| In a preview | Steps |
|---|---|
| Runs for real | Condition, Repeat for each, Shopify queries, the queries of a Liquid script, reads from the key-value store and Storage, reading and listing Files, listing and downloading with File transfer |
| Only reports what it would do | Ready-made actions, Shopify mutations, the actions of a Liquid script, HTTP requests (every method, also GET), Send email, Slack, Discord and Teams messages, Run function, Start another workflow, writes and deletes in the key-value store, Storage and Files, uploads, deletes and moves with File transfer |
A few details worth knowing:
- A Wait step does not wait in a test.
- A preview never retries a step.
- Download file downloads and checks the file, but does not store it.
- A step that was only previewed has no real result. Later steps that read its result get nothing, so a path that depends on such a result can look different in a preview than in a real run.
Test the whole workflow
- Select Test in the toolbar above the canvas.
- Check the Event (JSON). It starts with the sample event of the trigger. Paste a real event if you have one, or select Use the sample event to go back.
- Choose Preview (nothing is changed) or Run for real.
- Select Run preview (or Run for real).
The test runs the workflow as it is on screen, saved or not. The canvas marks the path the run took, and the panel lists every step that ran. Select a step to see what it returned. Open this test in the run history shows the full detail.
If the button is disabled, the banner tells you why: fix the problems listed above the canvas first. A test needs every step connected.
A test always runs the steps. It does not apply the trigger filter, so check a filter's rules against the values of a real event.
After a test, the variable picker offers the real fields of what each step returned, not only the known ones. That makes it much easier to pick a field of an API answer.
Test this step
Select a step. The side panel has a Test this step section.
- A step that only reads the event runs alone.
- A step that reads results of earlier steps runs those steps first. The section tells you which and why.
- A step inside a Repeat for each is tested with the first item of the list.
- If the event does not lead to this step, for example because a condition sends the run the other way, the step is not run and the section says so.
It uses the event and the preview or real choice of the Test panel.
Debug step by step
- Select Debug in the toolbar.
- Check the event and choose preview or real, as in a test.
- Optional: set breakpoints. While the debugger is open every step on the canvas has a dot. Select it to pause before that step.
- Select Start debugging.
- Use the bar above the canvas: Step runs the next step, Continue to the next breakpoint (or Continue to the end) runs on, Stop ends the session.
The canvas marks the step that runs next. The panel shows the data the next step will see: event, steps, vars, and inside a loop the current item. Secrets are hidden. Select a finished step to see what it returned.
The Key-value store section lists the keys your steps use, with their current values, and marks what changed. In a preview nothing is written, so the panel also shows what the value would be after the steps so far. Use Watch another key for keys a code step uses.
Good to know:
- A Wait step does not wait in the debugger.
- Editing the workflow ends the session.
- A session that is left alone ends by itself after 30 minutes.
- A stopped session appears in the run history as Cancelled. Stopping does not undo steps that already ran for real.
Related
A guided session with pictures: Tutorial: debug a workflow step by step.