Acerca de esta herramienta
Hacer pruebas negativas de un endpoint significa enviar el mismo body muchas veces con exactamente una cosa mal. Escribir esas variantes a mano es lento y es fácil olvidarse de alguna. Pega un JSON Schema y esta herramienta recorre sus palabras clave type, required, enum, minimum/maximum, minLength/maxLength, format e items para construir un payload válido, y después deriva una variante por regla: cada campo obligatorio eliminado, cada campo con el tipo incorrecto o null, cadenas un carácter fuera de sus límites de longitud, números un paso fuera de su rango, un valor de enum no válido, emails y fechas mal formados, una propiedad extra desconocida y un objeto vacío. Si pegas un body de ejemplo, cada campo presente se trata como obligatorio y los formatos se infieren a partir de los valores. $ref, allOf/anyOf/oneOf y pattern no se resuelven, así que revisa esos campos tú mismo.
Cómo usarla
- Pega un JSON Schema o el body real de una petición, o carga uno de los ejemplos. La detección automática decide de cuál se trata; puedes cambiarlo con el selector si hace falta.
- Copia el payload válido para tu test del camino feliz.
- Filtra las variantes negativas por categoría, despliega cualquiera para inspeccionarla o copiarla, o expórtalas todas como un array JSON de {name, payload} para alimentar un test data-driven.
Preguntas frecuentes: Generador de payloads de API
¿Qué es un payload de API?
Un payload de API son los datos que viajan en el body de una petición o respuesta, normalmente JSON en las APIs REST. Por ejemplo, una petición POST /users podría enviar {"name": "Asha", "email": "asha@example.com"}. El método, la URL y las cabeceras describen la petición; el payload es su contenido. En testing, los payloads de petición son tus entradas y los de respuesta son contra lo que haces las assertions, así que ambos deben ajustarse al contrato de la API.
¿Cómo genero payloads JSON para pruebas de API?
Empieza por el contrato de la API. Pega su JSON Schema, o el body de una petición real, en este generador y construirá un payload válido más una variante negativa por regla: un campo obligatorio ausente, un tipo incorrecto, un valor fuera de rango, un enum no válido y más. Expórtalos como JSON y recórrelos en tus tests. Para generar valores realistas en bloque, usa el generador de datos de prueba; para ejemplos ya hechos, consulta los payloads JSON de ejemplo.
¿Qué debe contener el payload de una petición POST?
Exactamente lo que el contrato de la API exige para crear el recurso: todos los campos obligatorios con el tipo y formato correctos, más los campos opcionales relevantes para el escenario. No debe incluir campos generados por el servidor como id o createdAt salvo que la API los espere. Envíalo con la cabecera Content-Type: application/json. Una creación correcta suele devolver 201 Created con el nuevo recurso o una cabecera Location; un payload no válido debe devolver 400 o 422 con un error claro.
¿Cómo creo payloads para pruebas negativas?
Parte de un payload válido y rompe exactamente una cosa por test, para que un fallo apunte a una única regla. Variantes típicas: eliminar cada campo obligatorio, enviar el tipo incorrecto o null, superar en uno los límites de longitud o numéricos, usar un valor de enum no válido o un email mal formado, añadir una propiedad desconocida y enviar un objeto vacío. Cada una debe rechazarse con un estado 4xx y un error útil, nunca con un 500. Este generador deriva esas variantes automáticamente a partir de un schema.
¿Cuáles son los formatos de payload JSON más comunes?
La mayoría de las APIs REST usan un objeto JSON, a menudo con objetos anidados, como un usuario con un address. Otras formas habituales son arrays de objetos para operaciones masivas; envoltorios que agrupan los resultados en campos data y meta; peticiones GraphQL con query y variables; y los problem details de RFC 9457 para errores, con type, title, status y detail. Explora bodies realistas de petición y respuesta en la biblioteca de payloads JSON de ejemplo.
¿Puedo generar datos de prueba aleatorios para pruebas de API?
Sí. Los datos aleatorios encuentran bugs que los valores elegidos a mano pasan por alto, pero deben ser reproducibles. El generador de datos de prueba crea nombres, emails, direcciones, UUID, números y fechas realistas con Faker, y una semilla fija devuelve siempre los mismos datos, de modo que un test fallido se puede repetir. Las librerías Faker para JavaScript y Python, o Datafaker para Java, hacen lo mismo dentro de tus tests. Para cadenas de casos límite, usa el generador de cadenas de prueba.
¿Qué código de estado deben producir los payloads negativos?
Normalmente 400 Bad Request o 422 Unprocessable Content, con un body de error que indique el campo. Sea lo que sea lo que documente la API, debe ser coherente entre endpoints, y ninguna de estas variantes debería producir jamás un 500.
¿Cómo uso el JSON exportado en un test?
Carga el array y recórrelo: en Playwright, for (const { name, payload } of variants) test(name, ...); en JUnit 5 usa un @MethodSource o un @ParameterizedTest con una fuente JSON; en Postman, úsalo como archivo de datos del collection runner.
¿Por qué no se genera “Null value” para algunos campos?
Si el schema permite null para un campo (type: ["string", "null"] o null en su enum), enviar null es válido, así que no es un caso negativo.