---
id: KB-IN-019
url: https://app.codecontract.io/ayuda/integraciones/probar-una-integracion-sin-ensuciar-los-datos
idioma: es
categoria: integraciones
audiencia: usuario
nivel: intermedio
actualizado: 2026-08-13
tambienEn: [en]
relacionados: [KB-IN-008, KB-IN-011]
citadoPor: [KB-IN-017]
---

# Probar una integración sin ensuciar los datos

_Lo que se prueba con datos reales sale a la calle de verdad: avisos, correos y registros que luego hay que explicar._

**Responde a:** probar una integración sin mandar avisos reales · cómo hago pruebas sin ensuciar · he lanzado una prueba y ha salido un correo · datos de prueba en producción

Toda integración pasa por una fase de prueba, y casi siempre se hace sobre lo que hay: se coge un expediente real porque es el que tiene los datos completos. Funciona a la primera y por eso nadie se da cuenta del problema hasta la semana siguiente.

## Qué pasa cuando se prueba con lo real

| Lo que hace la prueba | Qué provoca de verdad |
| --- | --- |
| Marcar un expediente como completado | Se disparan los avisos que dependan de ese estado |
| Crear una solicitud de ejemplo | Alguien de fuera recibe una petición que nadie quería mandar |
| Actualizar un dato para ver si viaja | Queda escrito en el histórico de algo real |
| Repetir el envío del aviso diez veces | Vuestro sistema recibe diez veces el mismo evento |

> [!IMPORTANT]
> La fila que más incidencias reales provoca es la segunda: **un aviso de prueba sobre un contacto real sale de verdad**. La plataforma no distingue una prueba de un envío en serio, porque para ella es exactamente el mismo acto. Es la llamada incómoda del día siguiente — un proveedor pidiendo explicaciones por una solicitud que no entiende — y la única forma de evitarla es que el destinatario de cualquier prueba seáis vosotros mismos.

## Cómo se prueba bien

1. **Un expediente de pruebas, con nombre que lo diga** — «PRUEBA — no usar», para que nadie lo confunda en un listado.
2. **Contactos de prueba con vuestras propias direcciones** — Si algo sale, os llega a vosotros.
3. **Probar primero el aviso, después la acción** — Ver el evento llegar a vuestro sistema no requiere tocar nada real.
4. **Y limpiar al terminar, dejando nota de qué era** — Lo que se queda ahí acaba contando en un informe.

> [!WARNING]
> Cuidado también con lo que la prueba no rompe pero sí ensucia: **los expedientes de prueba cuentan en los números**. Salen en los totales del mes, en la media de días para cerrar y en el informe que enseñáis a un cliente. Es la razón por la que conviene borrarlos al acabar y no «dejarlos por si acaso»: nadie recuerda seis meses después que aquellos cuatro expedientes de septiembre eran de una prueba de integración.

## Antes de dar por buena la integración

**En corto**

- Comprobad qué pasa cuando falla, no solo cuando funciona: es lo que va a pasar algún día.
- Provocad un error a propósito y mirad si alguien se entera.
- Y dejad escrito qué hace, para quien la mire dentro de dos años.

> [!NOTE]
> Si vuestra informática necesita un entorno separado para probar contra datos que no sean los vuestros, es una conversación que conviene tener antes de empezar a integrar, no en mitad de la prueba.

**¿Puedo probar con un cliente de confianza?**

Mejor no: la prueba deja rastro en su expediente, no solo en el vuestro.

**¿Y si necesito datos realistas?**

Copiad la forma, no el contenido: nombres inventados con la misma estructura.

**¿Cuánto conviene dejar los expedientes de prueba?**

Lo que dure la prueba. Después, fuera.

## Ejemplos

**Una empresa prueba su integración marcando como completado un expediente real.**

- Crea un expediente de prueba con contactos suyos y provoca un fallo a propósito

→ La prueba enseña qué pasa cuando falla, sin que ningún proveedor reciba nada raro.

**Se prueba en producción y se crean veinte expedientes de mentira.**

- Prueba en un entorno aparte
- Si no lo hay, usa datos marcados como prueba y ciérralos después

→ Los informes no arrancan mezclando pruebas con lo real.

**Las pruebas mandan correos a proveedores reales.**

- Usa contactos de prueba propios

→ Nadie de fuera recibe un correo de un ensayo.

**Se prueba el camino feliz y falla el día del error.**

- Prueba también qué pasa cuando el dato viene mal

→ El comportamiento ante el error se conoce antes.

**Terminan las pruebas y los datos se quedan.**

- Cierra y limpia lo de prueba antes de abrir

→ El arranque empieza limpio.

**No se sabe si lo probado es lo que va a producción.**

- Comprueba que la configuración es la misma

→ Lo probado es lo que se despliega.