How to build synthetic test records for a workflow

Why invent the data

Testing with live records means a mistake can email a real customer or change a real order. The n8n documentation describes data mocking as creating or simulating test data without connecting to real sources, and says pinning and mocking help you protect live systems from repeated test calls. Inventing the data yourself also lets you include cases that rarely happen but would hurt when they do.

Choose cases on purpose

Do not copy a random slice of last month. Decide what the workflow should do in each situation and invent one record for each. A useful starting set looks like this:

• A normal record that should pass straight through
• A record at each boundary, such as the smallest and largest allowed quantity
• A record with a missing required field
• A record with an unexpected format, such as a date written another way or a name with an accent
• A duplicate of an earlier record, sent twice
• A record that should go to a person for a decision rather than being handled automatically
• A very long or empty text field

Write the expected result first

For every invented record, write what should happen before you run anything: which route it takes, what message is sent, what gets saved, and what is refused. Without this note you will read the output and decide it looks right, which is a weaker test than comparing it with an answer you committed to beforehand.

Mock or pin the inputs

n8n distinguishes two ideas. Mocking creates test data, for example with the Code or Edit Fields nodes. Pinning saves data, mocked or real, and reuses it in later executions instead of fetching fresh data. It also lets you edit pinned data to check different scenarios without sending each one from the external system. The documentation says these are development features: pinning is not available for production executions. Whatever tool you use, keep the test inputs separate from the live setup so test records never reach real systems.

Keep personal data out

Use made-up names and addresses, and for email use reserved example names such as person@example.com and person@example.invalid. IANA maintains example.com and example.org for documentation and says they may be used as illustrative examples without prior coordination. RFC 2606 reserves the top level names .test, .example, .invalid and .localhost, and describes .invalid as intended for names that are obviously invalid at a glance, which suits a test address that should never belong to a real person.

A reserved name is a label, not a block, so do not rely on the domain alone to stop a message leaving your system. Turn off outbound sending in the test copy of the workflow, or point it at a controlled sink, meaning a mailbox or capture tool that you run and that collects messages instead of delivering them to outside recipients. IANA also says its example domain web services are best effort and not designed for production applications, so avoid designs that need those domains to respond.

If you must test against a copy of real records, treat the copy as sensitive and restrict who can see it. Never leave test messages able to send to real customers.

A hypothetical example

Imagine a workflow that routes quote requests: requests under a set value get an automatic acknowledgement, larger ones go to the owner. The test set holds a small request, one exactly at the threshold, one over it, one with no email address, one with an email address typed with a trailing space, and the same request submitted twice. The expected results are written down first. The test reveals that the threshold record is routed the wrong way, which is cheaper to find now than after a real customer waits. This example is hypothetical.

Keep the set and reuse it

Store the test records with the workflow notes. Each time the workflow changes, rerun the set and add a new record whenever a real problem shows up. Over time the set becomes a record of everything that has ever gone wrong.