Part 3 of the n8n Workflow Testing Series — if you have not read Articles 1 and 2 yet, Article 1 covers staging copies and Article 2 covers pinned data. Both techniques are used here.
Screenshot note: Some images are “n8n-inspired” mockups, not exact screen captures of your n8n environment—but the idea is still useful. Hint, hint, n8n Design Team… I am not asking for lasers, but I would not reject lasers.
“I Clicked Execute and It Worked”
There is a moment that almost every n8n builder has experienced. You finish a workflow, click Execute, watch all the nodes turn green, and feel a wave of relief. It worked. You are done.
Then you turn it on. And three days later something breaks in a way you never expected. A lead comes in with no email address. An API returns an error at midnight. A form submission has a field name that is slightly different from what your workflow expected. And suddenly your “working” workflow is doing something wrong — or doing nothing at all.
The problem is not that you tested. The problem is that “I clicked Execute and it worked” is not really a test. It is more like a first rehearsal with a perfect script and cooperative actors. Real life is messier than that.
A test case is a structured way of checking whether your workflow behaves correctly — not just when everything goes right, but when things go sideways too. And you do not need a background in software development to write one. You just need a little structure and the willingness to think about what could go wrong.
This article will show you exactly how to do that.
What a Test Case Actually Is
A test case is simply a written description of one specific thing you want to check about your workflow. It has three core parts:
The setup. What input or condition are you starting with? What does the data look like when it enters the workflow?
The expectation. What should the workflow do with that input? What is the correct outcome?
The result. What did the workflow actually do? Did it match your expectation?
That is it. A test case does not have to be technical or formal. It just has to be specific enough that someone else — or future you — could read it and understand exactly what was tested and what happened.
The reason you write these down before you test is important. When you decide in advance what the correct answer should be, you cannot talk yourself into accepting a wrong answer after the fact. If the workflow does something unexpected, you will notice — because you already wrote down what “correct” looks like.
The Six Types of Tests Worth Running
Before you start writing test cases, it helps to know the different kinds of situations you are trying to cover. Most workflows need to be tested against at least these six scenarios.
The Happy Path
This is the test where everything goes right. The input is complete, clean, and exactly what your workflow expects. Every API responds. Every field is present. The workflow runs from start to finish without any trouble.
You need this test to confirm that the workflow works at all. But it is also the easiest test to pass — which means passing it does not tell you very much. Think of the happy path as your starting point, not your finish line.
Missing Data
What happens when a required field is missing? What if the customer forgot to fill in their email address? What if the webhook payload arrives without a field your workflow depends on?
A workflow that has never been tested against missing data will often crash in an unhelpful way — or worse, continue running and do something wrong without throwing any error at all.
Duplicate Data
What happens when a record that already exists tries to come through again? If your workflow creates a new contact in a CRM, what does it do when that contact is already there? Does it create a duplicate? Does it update the existing record? Does it skip the submission entirely?
This is one of the most common sources of messy data in production systems, and it is easy to test for.
Failed API
What happens when an external service your workflow depends on goes down or returns an error? APIs fail. Rate limits get hit. Authentication tokens expire. If your workflow has never been tested against an API failure, you do not know whether it will crash silently, alert someone, retry, or do something else entirely.
You can simulate this in n8n by temporarily entering a wrong API key, or by using pinned data that mimics an error response.
Empty Search Result
What happens when your workflow searches for something and finds nothing? If your workflow looks up a customer ID and that ID does not exist, does it handle the empty result gracefully? Or does it try to pass an empty value to the next node and crash?
Unexpected Format
What happens when the data arrives in a shape your workflow did not expect? A number comes through as a string. A date is formatted differently. A field name has a typo or an extra space. These kinds of format mismatches are extremely common in real-world integrations and almost never show up in happy path testing.
A Simple Test Case Table
The best way to track your test cases is a simple table. You can keep this in a Google Sheet, a Notion page, an Airtable base, or even a plain text document. What matters is that you write it down before you test and fill in the results as you go.
Here is the format:
| Test Case ID | Scenario | Input / Condition | Expected Result | Actual Result | Pass / Fail | Notes |
|---|---|---|---|---|---|---|
| TC-01 | Happy path | All fields present and valid | Lead created, email sent, result logged | |||
| TC-02 | Missing email | Email field is blank | Workflow stops, error logged | |||
| TC-03 | Duplicate lead | Lead ID already exists in CRM | Existing record updated, no duplicate created | |||
| TC-04 | API failure | CRM returns a 500 error | Workflow retries or sends alert to admin | |||
| TC-05 | Empty search result | Lead lookup returns no match | Workflow creates new record or routes to fallback | |||
| TC-06 | Unexpected format | Amount field contains text instead of a number | Workflow catches error before processing |
Fill in the Actual Result and Pass / Fail columns as you run each test. Leave the Notes column for anything worth remembering — what broke, what you changed, or what still needs follow-up.
A Real Example: Lead Form Workflow
Let’s build a set of test cases for a specific workflow so you can see how this works in practice.
The workflow does four things when someone submits a contact form:
- A webhook receives the form submission
- The workflow checks whether a lead with that email already exists in the CRM
- If the lead is new, it creates a CRM record and sends a welcome email
- Either way, it logs the result to a Google Sheet
This is a common, realistic workflow. Here is what a full set of test cases looks like for it.
TC-01: Happy path — new lead with all fields
Input: A form submission with a valid name, email, company, and phone number. The email does not already exist in the CRM.
Expected result: A new CRM record is created. The welcome email is sent to the correct address. A new row is added to the Google Sheet with status “New Lead Created.”
TC-02: Missing email address
Input: A form submission where the email field is blank.
Expected result: The workflow stops before creating a CRM record or sending an email. An error is logged. No broken record is created.
TC-03: Duplicate lead — email already in CRM
Input: A form submission with an email address that already exists in the CRM.
Expected result: No new CRM record is created. The existing record is updated if needed. The Google Sheet logs “Duplicate — Record Updated” or “Duplicate — Skipped.”
TC-04: CRM API returns an error
Input: A valid form submission, but the CRM node receives a simulated error response. You can test this by temporarily entering a wrong API key in the CRM node’s credentials, or by using pinned data that returns an error-shaped payload. Note that different nodes handle errors differently — some will stop the workflow, others may continue. Test your specific node to see what actually happens.
Expected result: The workflow does not crash silently. It either retries, logs the failure to the Google Sheet, or sends an alert to the admin.
TC-05: Lead lookup returns no result
Input: A form submission where the lookup step returns zero results — the lead is not in the CRM, but the lookup itself also does not confirm a match.
Expected result: The workflow correctly identifies this as a new lead and routes it to the creation step, not to the duplicate handler.
TC-06: Name field contains only spaces
Input: A form submission where the name field is " " — not empty, but not a real name either.
Expected result: The workflow catches this before the welcome email goes out, or at minimum, the email does not say “Hello, !”
How to Actually Run Each Test Case
Once your test cases are written, running them is straightforward. Here is the process for each one.
Set up the input. Use pinned data in the webhook node to create the exact input your test case describes. Edit the pinned data JSON to match the scenario — blank the email field for TC-02, change the email to one that already exists in the CRM for TC-03, and so on. If you are not familiar with pinned data yet, Article 2 in this series covers it in detail.
Run the workflow. Click Execute Workflow in the n8n editor and watch what happens. Pay attention to which nodes turn green, which turn red, and what the output looks like at each step.
Check the actual result. Did the CRM record get created? Did the email go to the right place? Did the Google Sheet get a new row? Compare what actually happened to what you wrote in the Expected Result column.
Fill in the table. Write the Actual Result in your test case table, and mark it Pass or Fail. If it failed, write a quick note about what went wrong.
Fix and retest. If a test fails, fix the issue in the workflow, then run that test case again from the beginning. Do not move on until the test passes. And when you fix something, run the earlier tests again too — a fix in one place can sometimes break something else.
Why Failed Tests Are Good News
A failed test feels bad in the moment. You built something, you tested it, and it did not work. That is discouraging.
But think about the alternative. If you had not tested it, that same failure would have happened in production — with real customer data, at a moment you were not watching. A failed test is information. It tells you exactly where the problem is while you still have time to fix it.
Every failed test you catch in staging is one less incident in production. The goal of testing is not to prove that your workflow is perfect. It is to find out where it is not, so you can make it better before it matters.
Experienced builders do not feel embarrassed by failed tests. They expect them. The question is not whether your workflow will have problems — it is whether you find the problems before or after your customers do.
Common Mistakes Beginners Make
Writing vague test cases. “Test that the form works” is not a test case. It has no specific input, no expected result, and no way to know if it passed or failed. Be specific. Name the field. Name the expected behavior.
Not deciding the expected result before testing. If you run the workflow first and then decide whether the result was “good enough,” you will almost always talk yourself into accepting something that is not quite right. Write the expected result first, before you run anything.
Only testing the happy path. This comes up in every article in this series because it is the most common mistake in workflow testing. One green execution is not enough. Test the broken inputs too.
Not saving screenshots. When something fails, a screenshot of the error and the output panel is worth a lot. When you go back to fix the issue later, you will be glad you have a record of exactly what you saw.
Not retesting after fixes. You find a bug, fix it, and move on. But fixing one thing sometimes breaks another. Always rerun the full set of test cases after making changes — not just the one that failed.
Document Your Results
A test case table is only useful if you actually fill it in. Here is a copy-paste template you can use as a starting point for any workflow.
WORKFLOW TEST CASE LOG
Workflow name: [Your Workflow Name]
Version tested: [e.g. STAGING - Lead Form Workflow]
Test date: [Date]
Tester: [Your name]
---
TC-01
Scenario: Happy path — all fields valid
Input / Condition: [Describe the input]
Expected Result: [What should happen]
Actual Result: [What actually happened]
Pass / Fail:
Notes:
TC-02
Scenario: Missing required field
Input / Condition: [Describe the input]
Expected Result: [What should happen]
Actual Result: [What actually happened]
Pass / Fail:
Notes:
TC-03
Scenario: Duplicate record
Input / Condition: [Describe the input]
Expected Result: [What should happen]
Actual Result: [What actually happened]
Pass / Fail:
Notes:
TC-04
Scenario: API failure or error response
Input / Condition: [Describe the input]
Expected Result: [What should happen]
Actual Result: [What actually happened]
Pass / Fail:
Notes:
TC-05
Scenario: Empty search result
Input / Condition: [Describe the input]
Expected Result: [What should happen]
Actual Result: [What actually happened]
Pass / Fail:
Notes:
TC-06
Scenario: Unexpected data format
Input / Condition: [Describe the input]
Expected Result: [What should happen]
Actual Result: [What actually happened]
Pass / Fail:
Notes:
---
Overall result: PASS / FAIL / NEEDS MORE TESTING
Ready to move to production: YES / NO
Copy this into a Google Doc, Notion, or Airtable. Fill in the workflow-specific details, run each test, and record what you find. This document becomes your evidence that the workflow was tested — useful when you hand something off to a client or when a colleague asks what was checked before launch.
Use AI to Help
Writing test cases from scratch can feel intimidating the first time. AI tools are genuinely useful here because they can take a plain-English description of your workflow and turn it into a first draft of a test case table.
Here is a prompt you can use:
I have an n8n workflow that does the following:
[Describe your workflow step by step in plain English —
what triggers it, what it checks, what it creates or sends,
and what it logs.]
Please create a test case table for this workflow with
the following columns:
- Test Case ID
- Scenario
- Input / Condition
- Expected Result
Include test cases for:
- The normal happy path
- At least two missing or blank field scenarios
- A duplicate record scenario
- An API failure or error response
- An empty search result
- At least one unexpected data format
Format it as a simple table I can copy into a Google Sheet.
This gives you a solid starting point. You will still need to adjust the expected results based on how your specific workflow actually behaves, but the AI will do the work of generating the scenarios so you do not have to start from a blank page.
Zero to Hero Tip: Ask AI to Be Your QA Reviewer
Once you have written your test case table, paste it into an AI tool and ask it to review your work — not to generate more test cases, but to specifically look for gaps and weaknesses in the ones you already have.
Here is a prompt that works well:
I have written the following test cases for my n8n workflow.
Please review them as if you were an experienced QA tester
and tell me:
1. Which test cases are too vague and need more specific
expected results.
2. Which important scenarios I have missed entirely.
3. Which test cases overlap and could be combined.
4. Whether my expected results are specific enough to
clearly determine pass or fail.
Here are my test cases:
[Paste your test case table here]
This is a different kind of AI help than just generating ideas. You are asking the AI to critique your thinking rather than replace it. A good QA reviewer does not just run tests — they question whether the right tests were chosen in the first place. Getting that kind of pushback on your test cases before you run them can save you from a false sense of confidence after everything “passes.”
Production Readiness Checklist
Work through this list before you activate your workflow. If any box is unchecked, keep testing.
- I wrote out my test cases before running any tests
- I wrote an expected result for every test case before running it
- I tested the happy path and it passed
- I tested at least one missing field scenario
- I tested a duplicate record scenario
- I tested how the workflow handles an API error or failure
- I tested an empty search result
- I tested at least one unexpected or malformed input
- I recorded the actual result for every test case
- I marked every test case as Pass or Fail
- I retested all cases after making any fixes
- I saved screenshots of any failures
- All test cases currently show Pass
Production Readiness Question: If a real customer sent a broken or incomplete form submission right now, do I know exactly what my workflow would do?
If you are not sure, that uncertainty is the answer. Keep testing until you are sure.
Final Takeaway
A test case is not a complicated thing. It is just a written record of one specific situation you checked, what you expected to happen, and what actually happened.
The power of writing test cases is not in the format. It is in the discipline of deciding what “correct” looks like before you run anything — and then honestly recording whether you got there.
Most beginners skip this step because it feels like extra work. But test cases are what separate a workflow you hope works from a workflow you know works. They are how you catch the problems that happy path testing misses. And they are how you prove to yourself, your clients, and your teammates that the workflow was actually tested — not just clicked.
Write them. Run them. Record what you find. Then fix what is broken and run them again.
Next in the series: Article 4 — How to Validate Data Early in n8n