Tools & Workflows · Test pack & error cases
One request. One task. Even with duplicates in the batch.
Do not just check whether a good request works. Also check whether a bad one stays visible and whether a repeated ID within the same batch is detected. Running the workflow again processes the whole batch again.
Request to task · Version 1
One case, two workflow files.
With synthetic inputs, expected results, exact instructions and documented limits. No registration required.
The package documentation and the synthetic test data are in German; this is the same package as in the German edition, with unchanged file names. The workflow logic does not depend on the language.
Complete test pack (ZIP) ↓Open the files individually
- n8n workflow ↓ Import file
- Make blueprint ↓ Hand-written; cloud import and run still open
- Synthetic inputs ↓ No real requests
- Expected results ↓ Target values, not a measurement
- Setup guide ↓ Versions and prerequisites · in German
- Cloud test procedure ↓ Sequence of steps and log · in German
- Actual test report ↓ Execution and limits of the evidence
- File manifest ↓ SHA-256 for integrity
Four questions for any workflow
01 · Complete and new
Does a valid new request produce exactly one proposed task? Are the ID and the transferred details correct?
Failure signal: the run succeeds, but the task is missing or contains different data.
02 · Required field missing
Does the incomplete request stay visible, with an understandable reason and without any invented additions?
Failure signal: the input disappears somewhere between filter and output.
03 · The same request again
Is the repeat detected within the same batch without a second task being created? A changed text with the same valid ID is also treated as a duplicate. The source file is kept for checking.
Failure signal: a randomly generated new key makes every repeat look like a new request.
04 · Unexpected error
What happens outside the agreed text fields? n8n explicitly stops when the structure is wrong. Make does not yet have these additional input guards; an empty list can end without output. That is a named gap to close before a real connection, not a passed shared test.
Failure signal: “successful” counts only the good outputs and says nothing about the rest.
Expected is not observed
expected-results.json is the test oracle. test-report.json describes the actual execution. A schema that still fits cannot replace a Make cloud run. So always read the type of evidence in the report, not just a status.
The demo processes a limited test set. Real operation adds further cases: simultaneous requests, an abort after the task has been created, missing permissions, an unreachable target and a retry. Only testing those justifies statements about connected operation.
How to check the same case without automation
- Enter the valid request in a task list with a unique case ID.
- Before creating a second entry, search for that ID.
- Put incomplete requests on a separate review list and note the missing field.
- Count the inputs and all outputs. No input may disappear silently.
With only a few cases, this routine may be enough. It also gives you an understandable baseline to compare the automated workflow against.
If a download does not open
Save the file using the download link. JSON files are text files, and a browser may simply display them. Keep the file name and extension as they are. An HTML error page with a .json name is not a workflow. The ZIP contains the same version with a manifest. If something does not match, use the contact page and give the file name, version and error text, without sending credentials or customer data.
