An automation workflow is glue between systems you do not own, which makes it exactly the kind of code that breaks in ways unit tests of individual functions never catch. Testing workflows is its own discipline: verify each step in isolation, mock the external world, exercise the whole chain against sandboxes, and — most importantly — test the failures, because that is what all your retry and error handling exists for.
Test steps in isolation
Each step is a transformation or a call, and each is testable on its own. Given this input, does the mapping produce the right output? Given this API response, does the step parse it correctly? Isolating steps lets you cover the data-shaping logic — the source of a huge share of workflow bugs — quickly and deterministically, without invoking the whole workflow.
Mock what you don't control
You cannot let tests hit real external systems: it is slow, flaky, and occasionally destructive. Mock the external calls so you can drive them deterministically, including the responses you cannot easily produce on demand:
- Success responses, to verify the happy path maps correctly.
- Error responses — 429, 500, timeout — to verify retries and error handling actually trigger.
- Malformed or unexpected payloads, to verify the workflow degrades instead of corrupting data.
- Empty and boundary results, to verify the workflow handles 'nothing to do' gracefully.
End-to-end against sandboxes
Isolated and mocked tests miss the wiring between steps and the real quirks of the external APIs. Run the full workflow end to end against provider sandboxes or test accounts, so you catch integration mismatches — a field that is a string not a number, an auth scope that is missing — that no mock would reveal. Keep these fewer and slower; they are the integration check, not the bulk of your coverage.
The happy path usually works; it is the failures that bite in production. Deliberately inject timeouts, rate limits, and bad data in tests and assert that retries fire, dead-lettering happens, and no partial state is left behind. Untested error handling is error handling you are discovering for the first time during an incident.
A tested workflow has isolated step tests for its data logic, mocked external calls covering success and every failure mode, and a thin layer of end-to-end runs against sandboxes for the integration reality. Automation is trusted to run unattended — testing, especially of the failure paths, is what earns that trust.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.