Los datos de prueba para APIs determinan si una suite es confiable o si falla por razones ajenas al producto. Usuarios compartidos, registros creados manualmente y copias de producción convierten una regresión en un conjunto de dependencias ocultas. El problema no es únicamente técnico: cuando los datos incluyen información personal o financiera, también existe un riesgo de privacidad y acceso.
Una estrategia madura debe producir datos útiles, aislados y trazables sin exponer personas reales. Eso exige definir quién crea cada precondición, cómo se generan combinaciones relevantes, cuánto tiempo permanecen y cómo se eliminan. Este enfoque mejora simultáneamente estabilidad, paralelización y capacidad de diagnóstico.
Por qué los datos rompen una suite de APIs
Una prueba puede ser determinista en el código y aun así depender de un ambiente inestable. El usuario esperado fue bloqueado, otra ejecución consumió el saldo, un registro cambió de estado o la limpieza borró información ajena. El síntoma suele etiquetarse como “flaky test”, aunque la causa real sea una precondición no controlada.
- Datos fijos compartidos entre personas y pipelines.
- Dependencia del orden de ejecución.
- Identificadores codificados dentro de scripts.
- Limpieza global que afecta otras pruebas.
- Copias de producción sin un proceso de protección verificable.
- Datos sintácticamente válidos que no representan reglas reales.
Principios para datos de prueba seguros y útiles
1. Crear la precondición lo más cerca posible de la prueba
La prueba debe saber cómo obtener el estado que necesita. Puede llamar una API de preparación autorizada, usar un fixture versionado o ejecutar un proceso específico del ambiente. Evita depender de una persona que “deje listo” un usuario. La preparación automática hace repetible el escenario y documenta sus supuestos.
2. Aislar cada ejecución
Genera identificadores únicos incorporando un UUID, un prefijo del pipeline o una marca temporal controlada. El aislamiento permite ejecutar casos en paralelo sin que compartan cuentas, órdenes o recursos. La prueba debe guardar los identificadores creados para consultarlos y limpiarlos después.
3. Representar reglas, límites y estados
Datos aleatorios no equivalen a buena cobertura. Diseña particiones: valores normales, límites, combinaciones inválidas, estados previos y roles. Si una API calcula comisiones por moneda y tipo de cliente, la matriz debe representar esas reglas, no producir cientos de montos sin propósito.
4. Minimizar información sensible
Utiliza únicamente los campos necesarios para el escenario. La guía de privacidad en el ciclo de desarrollo del ICO recomienda definir la cantidad apropiada de información personal y protegerla también en ambientes de desarrollo.
5. Separar generación, uso y limpieza
Una fábrica o builder puede producir datos válidos con valores por defecto seguros y permitir cambios explícitos para cada caso. La prueba consume el objeto creado y registra su propiedad. La limpieza elimina únicamente esos recursos, incluso si la validación falla.
Datos sintéticos, anonimizados y enmascarados
| Enfoque | Uso adecuado | Riesgo que debe revisarse |
|---|---|---|
| Sintético diseñado | Pruebas funcionales, límites y automatización continua | No representar distribuciones o relaciones reales |
| Enmascarado | Ambientes que requieren estructura similar a producción | Transformaciones reversibles o campos olvidados |
| Anonimizado | Análisis donde ya no debe identificarse a una persona | Posibilidad de reidentificación al combinar datos |
| Pseudonimizado | Procesos controlados que necesitan relacionar registros | La información continúa siendo protegida y la clave debe aislarse |
No uses “sintético” como sinónimo automático de privado. NIST estudia el equilibrio entre utilidad, fidelidad y privacidad de datos sintetizados y desidentificados. Un conjunto puede parecer artificial y aun reproducir registros o relaciones que faciliten identificar información original.
Para pruebas funcionales suele ser más seguro crear datos deliberadamente ficticios y reconocibles, sin derivarlos de personas reales. Cuando una organización necesita distribuciones de producción, el proceso debe incluir evaluación de privacidad, acceso restringido y validación de utilidad.
Arquitectura práctica de datos para una suite de APIs
- Builder: construye payloads válidos con valores seguros.
- Factory: crea el recurso mediante una interfaz soportada.
- Registry: conserva los identificadores creados por la ejecución.
- Scenario data: modifica únicamente los campos relevantes para cada regla.
- Cleanup: elimina o expira recursos propiedad de la prueba.
- Diagnostics: registra referencias útiles sin secretos ni PII.
Esta separación evita copiar grandes payloads en cada caso. También permite cambiar una regla común —por ejemplo, el formato de un identificador— en un punto controlado, sin ocultar qué dato específico modifica cada prueba.
Ejemplo: datos para probar una transferencia
| Precondición | Cómo crearla | Propiedad de la prueba |
|---|---|---|
| Cliente activo | Factory con identidad ficticia | Usuario único de la ejecución |
| Cuenta origen | API de preparación con saldo controlado | Saldo y moneda conocidos |
| Cuenta destino | Factory independiente | No compartida con otros casos |
| Transferencia | API bajo prueba | Referencia e idempotency key únicas |
| Resultado | Consulta de estado y movimientos | Identificadores guardados para diagnóstico |
El escenario puede variar saldo, moneda, límites y permisos sin usar cuentas reales. Para cubrir errores, consulta la guía de pruebas negativas de APIs. Para definir qué validar después de crear los datos, revisa las capas de validación más allá del código 200.
Limpieza: eliminar, expirar o reconstruir
No todos los recursos deben borrarse directamente. En algunos dominios, eliminar transacciones rompe auditoría. Existen tres estrategias:
- Eliminación dirigida: para recursos temporales sin trazabilidad obligatoria.
- Expiración: datos con prefijo de prueba y política de retención limitada.
- Ambiente reconstruible: base conocida que se recrea entre ejecuciones controladas.
La limpieza debe ejecutarse aun cuando una aserción falle, pero nunca mediante consultas amplias basadas solo en fecha o nombre. Conserva un registro de propiedad y aplica límites para evitar eliminar datos de otra ejecución.
Datos y ejecución paralela
Antes de paralelizar, elimina dependencias compartidas. Cada worker necesita su propio usuario o namespace, referencias únicas y cuotas suficientes. Si todos modifican una configuración global, la paralelización amplifica la inestabilidad. Algunos casos que validan límites globales deben mantenerse seriales y explícitamente aislados.
Controles para ambientes no productivos
- Acceso por rol y necesidad, no por comodidad.
- Secretos separados de producción.
- Retención y limpieza documentadas.
- Logs con redacción de tokens y datos personales.
- Proveedores en modo sandbox y comunicaciones claramente marcadas.
- Monitoreo de volumen y uso anómalo.
Estos controles son parte de la estrategia de pruebas de APIs para producción: la calidad del resultado depende también de la seguridad y gobernanza del ambiente donde se obtiene.
Métricas para mejorar la estrategia
- fallos provocados por datos inexistentes o modificados;
- colisiones de identificadores entre ejecuciones;
- tiempo dedicado a preparar y limpiar datos;
- recursos de prueba que exceden la retención;
- porcentaje de escenarios capaces de ejecutarse en paralelo;
- incidentes de exposición en logs o ambientes no productivos.
Preguntas frecuentes
¿Puedo copiar producción y enmascarar algunos campos?
Solo con un proceso formal que cubra todos los campos, relaciones, texto libre, archivos y posibilidad de reidentificación. Para muchas pruebas funcionales es preferible crear datos sintéticos diseñados.
¿Los datos aleatorios mejoran la cobertura?
Únicamente si la generación respeta reglas y conserva la semilla o los valores usados para reproducir el fallo. La aleatoriedad sin modelo produce combinaciones irrelevantes y diagnósticos difíciles.
Conclusión
Los datos de prueba para APIs deben tratarse como parte del diseño de la suite, no como una precondición manual. Crear datos ficticios, únicos, relevantes y con un ciclo de vida controlado reduce falsos fallos y protege información sensible. El resultado es una automatización capaz de escalar sin perder confianza.