Output mocking

Replace a node's real action with a value you define, or a response that an LLM generates, during a debug run, to test the nodes after it in isolation.

Output mocking replaces a node's output during a debug run, so the node's real action does not run. It is useful for testing the nodes after it, called downstream nodes, when the real action is slow, expensive, or depends on something that is not available during a debug run.

How mocking works

When a mock is enabled on a node, the debug run doesn't run the node, and passes the mocked output values to the nodes after it. They receive the mocked values as if the node had run normally.

Mocks apply only during debug runs. They're never active in deployed workflows.

Setting up a mock

A mock is configured in the expanded view of the node, which opens from the node's hover toolbar. The Output column of the expanded view has a mode menu, at its top right, with three options:

• Live: uses the real response from the node. This is the default.
• Static mock: always returns a value that you define in the column.
• Generated: returns a response that an LLM generates each time the node runs.

A static mock is written as JSON, a text format for structured data, and must match the node's output schema, the list of fields the node produces. Use Generated when you need realistic, varied output and don't want to write it yourself. Use Static mock when a test needs the same value every time, for example to check one branch.

Common use cases

• Quick Form and Action App nodes: simulate an approved or rejected response without waiting for a real approver.
• HTTP Request nodes: simulate a specific API response, including error responses, to test the error handling paths.
• Agent nodes: simulate the output of an AI agent to test how the workflow handles different agent responses.
• Subflow nodes: simulate the output of a subflow to test the parent workflow in isolation.

Resetting mocks

A workflow uses real data again once the Output mode is set back to Live on each mocked node. Mocks aren't saved in the deployed workflow.

Common mistakes

• Deploying with a mock still enabled: mocks are turned off automatically when you deploy, so deployed runs always use real data. A mock left on during the final test run, though, means you tested against sample data, not the real result.
• Entering static mock data that does not match the node's output schema: if the mocked JSON does not match the shape the nodes after it expect, runtime errors appear that would not happen with real data. The mock needs to match the schema exactly.
• Mocking too many nodes at once: if five nodes are mocked to test the sixth, a passing test says little. Mock only the nodes that block the part under test.

Next steps

• Debugging basics: tips for running and reading a debug run.
• Evaluations: automated quality checks on workflow output.
• Quick Form: the node that waits for a human's response.
• Agent node: the node that runs an AI agent.
• Community: ask questions and share workflows with other builders on the UiPath Forum.