> ## Documentation Index
> Fetch the complete documentation index at: https://learn.workflow.dog/llms.txt
> Use this file to discover all available pages before exploring further.

# Testing workflows

> Test a workflow with representative trigger data and verify each branch.

Testing a workflow means sending a real event through its configured trigger,
then inspecting what each action received and produced. WorkflowDog does not
currently have a generic **Test Run** button.

## The test loop

<Steps>
  <Step title="Save the graph and trigger">
    Finish the change, save any open trigger configuration, and wait until the
    editor header says **Saved!**. Sending an event earlier can start a run from
    the previous graph.
  </Step>

  <Step title="Enable the workflow">
    A paused workflow does not accept new trigger events. Follow [Enable and
    pause](/essentials/enable-and-pause) if the workflow is not live.
  </Step>

  <Step title="Send one representative event">
    Cause the event the trigger is designed to receive. Use realistic values,
    including optional fields and attachments that matter to the automation.
  </Step>

  <Step title="Inspect the run">
    Open the workflow's runs, select the new run, and inspect trigger data,
    action outputs, and node errors.
  </Step>

  <Step title="Change one thing and repeat">
    Deselect the historical run, edit the current graph, wait for **Saved**, and
    send another event. Compare the new result with the expected outcome.
  </Step>
</Steps>

## Send the right event

| Trigger              | Useful test event                                                       |
| -------------------- | ----------------------------------------------------------------------- |
| URL                  | Open its URL for a `GET`, or send the exact method and body you expect. |
| Webhook              | Send a `POST` with representative JSON.                                 |
| Form Submission      | Submit the actual form, including a file if the workflow handles files. |
| Gmail or Outlook     | Send an email that matches the configured subject or label filter.      |
| Google Form Response | Submit the configured Google Form.                                      |
| TidyCal booking      | Create a real test booking.                                             |
| Schedule             | Temporarily use a near-future recurrence and wait for it to fire.       |
| Sub-Workflow         | Run it from a parent workflow with a representative **Payload**.        |

For HTTP request formats and response behavior, see
[HTTP endpoints and webhooks](/guides/http-webhooks). For provider account and
filter setup, see [Service triggers](/guides/service-triggers).

## Inspect more than the final result

A correct final value can hide a broken branch that happened not to affect this
event. Check:

* the **Data from Trigger** outputs,
* each action that should have run,
* values on output handles,
* node-level errors,
* branches intentionally skipped by conditions, and
* side effects in the destination service.

Actions on independent branches can run concurrently. Do not use their visual
left-to-right order as evidence that one finished before the other. Add a data
connection or **Wait For** dependency when order matters.

Historical runs keep the graph snapshot used when they started. Use that
snapshot to understand an old result; use the current graph for the next test.
See [Workflow runs](/essentials/workflow-runs) and
[Troubleshooting runs](/guides/troubleshooting-runs) for the detailed
inspection workflow.

## Reuse an event after the first test

After you have one representative run, **Rerun** can reuse its trigger payload
against the workflow's current saved graph. This is useful when repeatedly
tuning transformations or branch logic.

<Warning>
  Rerun repeats the stored trigger data; it does not recreate the external
  event. It may repeat side effects such as sending messages, creating rows, or
  calling APIs. Disable or isolate destructive actions before using it as a
  tight test loop.
</Warning>

## Test the unhappy paths

Before relying on the workflow, send cases that exercise its boundaries:

* a missing optional field,
* an empty list,
* a value in the wrong format,
* a false condition,
* an expired or disconnected service account, and
* a downstream service error.

An action error stops dependent actions from receiving its normal outputs, but
independent branches can continue. Use
[Meta controls](/building/meta-controls) when the workflow should recover,
report, or clean up after a failed action.