Skip to main content
Testing is layered so you can isolate configuration before running the full graph.

​
Test a node

Select a node, provide any required mapped sample input, and choose Test node. The result appears beside the graph. Browser locator tests use the active managed session; workflow-state nodes preview changes without committing them. If the node depends on earlier output, choose a compatible previous execution snapshot or supply an explicit sample override. The snapshot must belong to the same workflow. The test log states that only this node ran, so a successful test should not be read as evidence that its producer was re-executed. Collection nodes accept pinned arrays including empty, single-item, mixed-type, missing-field, and null examples. Merge accepts pinned collections independently under each stable input ID. Filter and Switch evidence shows branch counts and selected items; Aggregate and Remove Duplicates show before/after counts. Loop runs use the configured bounded sample and may execute the connected body, so they are not labelled harmless. Pinned data is development evidence only. Scheduled, published, and deployed runs resolve their real control-edge outputs and typed bindings instead. Side-effecting and destructive nodes do not become harmless in test mode. sndbox can require explicit confirmation for commands, deletion, upload, communication, or other bounded actions.

​
Validate the graph

Validation checks required configuration, trigger and connection rules, typed bindings, permission state, and node-specific constraints. Fix errors before using Run. A warning should be reviewed; it is not silently treated as success.

​
Run the revision

A manual run uses the saved workflow revision. Keep the execution drawer open to follow node state. After completion, inspect resolved values rather than assuming the canvas configuration is what reached an external service. Before publishing or scheduling, exercise at least:
  • the normal path and each Condition branch;
  • empty, missing, and maximum-size inputs where relevant;
  • a denied permission or unavailable connection;
  • an external timeout or non-success response; and
  • cancellation while a delay, browser wait, AI request, command, or approval is pending.
For write, send, delete, and command nodes, use a disposable target or a dedicated test account. A Test node action can still change the real world after confirmation.

​
Browser failures

Use locator attempts, current URL, page title, console errors, failed requests, screenshot, and trace references. When available, retry in headed mode or re-record the failed interaction.

​
Read a failed test

Start with the stable error code or node error, then compare resolved input with the node’s reference page. A validation error means the operation did not begin. A timeout can mean the action began but its success condition was not observed. For an external mutation with an uncertain outcome, inspect the destination before retrying and follow Retries and recovery.