Testing an automation

Testing in Nodest happens step by step. You run an individual step against your real connected tool, look at what comes back, and use that data to configure everything downstream. By the time you activate, each step has already proven it works.

Why test a step at all?

Two reasons, and the second is the one people underestimate.

The obvious one: you find out whether the step is configured correctly before it runs on live events.

The important one: testing a step is what makes its data available to later steps. The result is saved as that step's sample, and the variable picker can only offer fields it has actually seen. Until you've tested the trigger, later steps have nothing to map from.

That's why the order matters: test the trigger first, then build the rest.

Testing a trigger

Run the test on your trigger node and Nodest fetches a real record from the connected tool — an actual recent order, a real form submission — and saves it as the trigger's sample data.

Now open any field on a later step, switch it to variable mode, and the fields from that record are listed and ready to map.

Fetch a sample that's representative. Fields that were empty in the record you pulled are left out of the picker entirely. If you test against an order with no shipping note, "shipping note" won't be offered, even though the field exists. Pull a record with the fields you care about actually filled in.

Testing an action

Actions can be tested too — and this is the one to be careful with.

Testing an action really performs it. It isn't a simulation. If the action creates a database entry, the entry is created. If it sends a message, the message is sent. There's no sandbox between the test and your live tools.

So test actions against something safe: a scratch database, a private channel, your own email address. Once it works, point the field at the real destination.

The upside is the same as for triggers — the response is saved as that step's sample, so a later step can map values the action returned, like the ID of the record it just created.

Which steps can be tested?

Triggers and actions. Filters, branches, and delays don't call anything external, so there's nothing to test in isolation — you verify those by looking at a real run and checking which path it took.

Some triggers can't be tested either. Where a tool has no way to hand back a representative example, the step ships with a prepared sample instead, so the variable picker still works.

Verifying the whole automation

Once the individual steps are right, activate the automation and cause the event for real — place a test order, submit the form.

Then open the run history. Every step that executed is recorded with the data that went into it and the result that came out, so you can confirm the correct values arrived rather than assuming they did. If a step failed, the run stops there and shows the error.

A safe way to test on a live site

If you don't want a test order sitting in your real data:

1. Use a filter early on, matching something only your test will produce — a specific email address, a particular product.
2. Point actions at a scratch destination while you verify.
3. Once the run history shows the flow behaving, switch the destination and remove or widen the filter.