Datos dinámicos y pruebas data-driven

El problema de los datos fijos

Si tu request siempre manda ana@test.cl, la segunda vez que lo corras puede fallar por "email ya registrado". Y probar 5 teléfonos distintos copiando el request 5 veces es justo lo que la lección de particiones te enseñó a no hacer. La solución: datos dinámicos y ejecución data-driven.

Variables dinámicas: datos frescos en cada corrida

Postman trae generadores integrados que se usan como variables:

{
  "nombre": "{{$randomFullName}}",
  "email": "{{$randomEmail}}",
  "telefono": "+56 9 {{$randomInt}}"
}

Cada envío genera valores nuevos. {{$randomEmail}} te da un email único, evitando el choque por duplicados y haciendo el test repetible.

Pre-request scripts: preparar antes de enviar

A veces necesitas calcular algo justo antes de enviar (una fecha futura, un id, una firma). Eso va en la pestaña Pre-request Script, que corre antes del request:

// Pre-request Script: fecha de mañana en formato ISO
const manana = new Date(Date.now() + 86400000).toISOString();
pm.environment.set("fechaReserva", manana);
// luego en el body: "fecha": "{{fechaReserva}}"

Data-driven: un test, muchos datos

Aquí está la potencia real. En vez de un request por caso, usas el Collection Runner con un archivo de datos. Un CSV así:

telefono,esperado
+56 9 1234 5678,200
12345678,400
+56 9 abcd 5678,400
,400
+56 9 1234 567,400

En el request usas {{telefono}}; en Tests comparas el status con {{esperado}}. Corres la colección apuntando al CSV y Postman ejecuta el request una vez por fila, inyectando los datos de cada una. El reporte muestra 5 ejecuciones independientes: sabes exactamente qué partición se rompió.

Esto es la matriz de casos de la técnica de particiones, ejecutada automáticamente. Y es el formato que Newman consume para correrla en CI (lección 6).

Comprueba lo aprendido en el quiz y arma tu prueba data-driven en el reto.