---
id: KB-IN-019
url: https://app.codecontract.io/help/integrations/testing-an-integration-without-messing-up-real-data
idioma: en
categoria: integraciones
audiencia: usuario
nivel: intermedio
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-IN-008, KB-IN-011]
citadoPor: [KB-IN-017]
---

# 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._

**Responde a:** 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

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.

> [!WARNING]
> 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

**En corto**

- Check what happens when it fails, not only when it works: that is what will happen one day.
- Cause an error deliberately and see whether anyone notices.
- And write down what it does, for whoever looks at it in two years.

> [!NOTE]
> 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.

## Ejemplos

**A company tests its integration by marking a real file as completed.**

- Creates a test file with its own contacts and deliberately causes a failure

→ The test shows what happens when it breaks, with no supplier receiving anything odd.

**Testing happens in production and twenty fake files get created.**

- Tests in a separate environment
- If there is none, uses data marked as test and closes it afterwards

→ Reports do not start out mixing tests with real records.

**The tests send emails to real suppliers.**

- Uses your own test contacts

→ Nobody outside receives an email from a trial.

**The happy path is tested and it fails on the day of the error.**

- Also tests what happens when the data arrives wrong

→ Behaviour under error is known beforehand.

**Testing finishes and the data stays.**

- Closes and clears the test material before opening

→ Go-live starts clean.

**Nobody knows whether what was tested is what goes live.**

- Checks the configuration is the same

→ What was tested is what gets deployed.