Testing and keeping code safe
🎯You'll be able to
Test code steps with pinned awkward data, fail loudly on bad input and keep secrets out of code.
🏠The everyday picture
A tailor measures twice before cutting cloth, because a wrong cut can't be undone. A code step deserves the same care before it changes real records.
📘What it really is
-
Pin test data on the node before the Code node, including awkward cases: an empty list, a missing field, a very large order, a duplicate.
-
Check outputs, not just "no errors": compare counts and totals with a manual calculation.
-
Fail loudly on bad input. Throwing an error with a clear message (
throw new Error('Missing price for SKU ' + sku)) is safer than producing wrong data quietly; DA6 shows how to send that error to a person. -
Keep secrets out of code. API keys belong in n8n credentials, not typed into a Code node, where anyone who opens the workflow or an export can see them.
-
Keep it readable: a clear node name, a short note on what it does, and comments for any rule a business person gave you.
- Save versions: export the workflow or use n8n's version history before changing a code step that touches real data.
📝A worked example
Before switching on the weekly CRM tidy-up, you build a test checklist:
| Test input | Expected result | Actual |
|---|---|---|
| 0 contacts | Report: before 0, after 0; no errors | ✓ |
| 3 contacts, no duplicates | 3 kept | ✓ |
| 2 records for one phone, different dates | Newer kept, older's filled fields preserved | ✓ |
| Contact with no phone | Skipped and listed in the report | ✗ at first: it vanished silently |
The fourth test found a gap: contacts without a phone were dropped from the output. You add them to the report so a person sees them, and rerun every test.
🌍Where it's used
- Any code that writes to real records: CRMs, accounts, stock.
- Handovers: a clear test list lets another person change the code safely.
- Audits: clients ask how you know an automation is correct.
📝Case scenario
A freelancer hands over a workflow with an API key typed into a Code node. The client shares the workflow file with a new agency, and the key is now in someone else's hands. You move the key into n8n credentials, ask the client to replace the key with the provider, and add a handover note that code steps should read keys only from credentials.
🖱️Try it
Write a test table like the one above for your deduplication step from Lesson 4, with at least five rows, including an empty input and a missing field. Run each one with pinned data and record the result.
⚠️Common mistakes
- Testing only the happy path. Sign: the first empty list breaks production. Fix: pin an empty list, a missing field and a duplicate.
- Swallowing errors. Sign: the run succeeds but outputs nothing. Fix: throw an error with a clear message so the error workflow alerts someone.
🛠️For your project
Each starter code file has a small self-test. Keep those tests and add your own for the cases your projects meet; they are a quality item in the marking guides.
✅Quick check
Why is throwing an error with a clear message better than quietly skipping bad data?
Show the answer
It stops wrong data from spreading and tells a person exactly what to fix.
Where should an API key used by a workflow be stored?
Show the answer
In the platform's credentials store, not typed into a code step.