Test and debug

DRAGOPS provides several tools for testing patterns before you deploy them. You can run tests with sample data, pin node outputs for repeatable debugging, and capture live webhook payloads directly in the editor.

Run a test

Test mode lets you execute your pattern with sample data without deploying it.

1. Select Run in the toolbar at the top of the editor.
2. In the test dialog, provide sample event data as JSON. The structure depends on your trigger type — for an On Webhook trigger, this includes body, headers, query, and method fields.
3. Select Run.

{
  "body": { "action": "opened", "issue": { "title": "Bug report" } },
  "headers": { "content-type": "application/json" },
  "query": {},
  "method": "POST"
}

The pattern executes immediately, and results appear in the console at the bottom of the editor.

Console

The console shows real-time output as each node runs during a test. Every log entry is timestamped and labeled with the node that produced it.

You can see:

• Log output — Values logged by Log nodes in your pattern
• Node execution order — Each node reports when it starts and finishes
• Error details — If a node fails, the console shows the error message and which node caused it
• Execution timing — How long each node and the overall pattern took to run

Use the console to verify that data flows through your pattern as expected and that each node receives the inputs you intend.

Data pinning

Data pinning lets you freeze a node's output value so it stays the same across multiple test runs. This is useful when you want to test downstream logic without re-running the entire pattern from the trigger.

Pin a node's output

1. Run a test to generate output data on your nodes.
2. Select the node whose output you want to freeze.
3. Pin its output data from the node's context menu.

A pin icon badge appears on the node to indicate that its output is pinned. On subsequent test runs, that node uses the pinned value instead of re-executing.

When to use pinning

• Isolate a section of your pattern. Pin the nodes before the section you are working on, then iterate quickly on the downstream logic.
• Reproduce a specific scenario. If a test run produces an interesting edge case, pin that data so you can debug it repeatedly.
• Skip slow operations. If your pattern makes HTTP requests or calls other patterns, pinning those nodes lets you test the rest of the flow without waiting for external calls.

Clear pinned data

When you are done debugging, clear pinned data from the node's context menu to return to normal test execution. Pinned data does not affect deployed patterns — it only applies to test runs in the editor.

Tap mode

Tap mode lets you capture a real webhook payload in the editor without deploying your pattern. This is the fastest way to get real-world data into your test workflow.

Capture a live payload

1. Select Run in the toolbar, then select Listen for Test Event.
2. The editor displays a temporary webhook URL and begins listening for incoming requests.
3. Send a test request to the displayed URL from an external service, a browser, or a tool like curl.
4. Within seconds, the incoming payload appears in the test dialog, pre-filled and ready to use.

curl -X POST https://your-tap-url \
  -H "Content-Type: application/json" \
  -d '{"event": "test", "user": "demo"}'

Why use tap mode

• No guessing at payload structure. Instead of writing sample JSON by hand, capture the exact payload your integration sends.
• Test before deploying. Verify that your pattern handles real data correctly without putting it live first.
• Fast iteration. Capture a payload, run a test, adjust your pattern, and capture again — all without leaving the editor.

Tap mode listens for a limited time and accepts a single request. After the payload is captured, the temporary URL stops accepting requests. You can start a new tap session at any time.

Debugging workflow

A typical debugging session combines these tools:

1. Start with tap mode to capture a real payload from your integration.
2. Run a test with the captured data to see how your pattern handles it.
3. Check the console for errors or unexpected values.
4. Pin the output of nodes that produced correct results.
5. Adjust the downstream logic and re-run the test — pinned nodes skip re-execution.
6. Clear pinned data when everything works and run a full end-to-end test.