Testing actions in the action builder

Actions can be tested from the builder, and the cases worth testing are the ones nobody thinks of. Every step sends a real request, so use test data.

Actions can be tested from the builder, and the cases worth testing are the ones nobody thinks of. Every step sends a real request, so use test data.

Test from the builder

1. Save the action flow first. The test runs against what is saved, not what is on screen.
2. Open the Test action flow sidebar and fill in the inputs. Only the variable ones need values; what the trigger would supply is simulated.
3. Run it.
4. Read what came back, not just whether it succeeded.

The five cases

1. A normal request. The one you built for.
2. Something that does not exist. An order number with no match. What comes back, and is it usable?
3. An empty result. A customer with no orders. Different from an error and often handled worse.
4. Bad input. A malformed number, or a letter where a digit belongs.
5. The other system down. Hard to arrange and worth thinking through even if you cannot test it.

Cases two and three are where an AI agent says something confidently wrong to a customer, because nothing told it what an empty answer means.

Read the response, not the status

A call that succeeds and returns something unexpected is worse than one that fails. Look at the actual content and ask what an AI agent would say having received it.

Test again after the other side changes

Actions break when the system at the other end changes, and nothing tells you. Where an action matters, test it periodically, and certainly after anyone announces a release over there.

See also

• Creating an action
• Testing a webhook and finding faults
• Testing actions