Integrations
Testing an integration without messing up real data
What you test with real data really goes out: notices, emails and records you then have to explain.
Every integration goes through a testing phase, and it is nearly always done on whatever is there: you grab a real file because it is the one with complete data. It works first time, which is why nobody notices the problem until the following week.
What happens when you test on the real thing
| What the test does | What it actually triggers |
|---|---|
| Marking a file as completed | Any notices depending on that status fire |
| Creating a sample request | Someone outside receives a request nobody meant to send |
| Updating a field to see if it travels | It is written into the history of something real |
| Resending the notice ten times | Your system receives the same event ten times |
Important
The row that causes the most real incidents is the second: **a test notice on a real contact genuinely goes out**. The platform does not tell a test from a real send, because to it they are exactly the same act. That is the awkward call the next day — a supplier asking about a request they do not understand — and the only way to avoid it is for the recipient of any test to be you.
How to test properly
- 1
A test file, named so it says so
«TEST — do not use», so nobody mistakes it in a listing.
- 2
Test contacts using your own addresses
If anything goes out, it reaches you.
- 3
Test the notice first, the action after
Watching the event reach your system touches nothing real.
- 4
And clean up when finished, noting what it was
Whatever stays behind ends up counting in a report.
Watch out
Watch out too for what the test does not break but does pollute: **test files count in the numbers**. They show in the monthly totals, in the average days to close and in the report you show a client. That is why they are worth deleting rather than left «just in case»: nobody remembers six months later that those four September files came from an integration test.
Before signing the integration off
Worth knowing
If your IT team needs a separate environment to test against data that is not yours, that is a conversation worth having before integrating, not halfway through testing.
›Can I test with a friendly client?
Better not: the test leaves a trace in their file, not only yours.
›What if I need realistic data?
Copy the shape, not the content: made-up names with the same structure.
›How long should test files stay?
As long as the test. After that, out.
A real case
The situation
A company tests its integration by marking a real file as completed.
What you do
- Creates a test file with its own contacts and deliberately causes a failure
What you get
The test shows what happens when it breaks, with no supplier receiving anything odd.
The situation
Testing happens in production and twenty fake files get created.
What you do
- Tests in a separate environment
- If there is none, uses data marked as test and closes it afterwards
What you get
Reports do not start out mixing tests with real records.
The situation
The tests send emails to real suppliers.
What you do
- Uses your own test contacts
What you get
Nobody outside receives an email from a trial.
The situation
The happy path is tested and it fails on the day of the error.
What you do
- Also tests what happens when the data arrives wrong
What you get
Behaviour under error is known beforehand.
The situation
Testing finishes and the data stays.
What you do
- Closes and clears the test material before opening
What you get
Go-live starts clean.
The situation
Nobody knows whether what was tested is what goes live.
What you do
- Checks the configuration is the same
What you get
What was tested is what gets deployed.
This article answers
- testing an integration without sending real notices
- how to test without polluting data
- I ran a test and an email went out
- test data in production