À propos de cet outil
Faire du test négatif sur un endpoint, c’est envoyer le même corps de nombreuses fois avec exactement une erreur à chaque fois. Écrire ces variantes à la main est long, et il est facile d’en oublier une. Collez un JSON Schema : l’outil parcourt ses mots-clés type, required, enum, minimum/maximum, minLength/maxLength, format et items pour construire un payload valide, puis en dérive une variante par règle : chaque champ obligatoire supprimé, chaque champ avec un mauvais type ou à null, des chaînes d’un caractère hors de leurs limites de longueur, des nombres d’un pas hors de leur plage, une valeur d’enum invalide, des e-mails et dates mal formés, une propriété inconnue en trop et un objet vide. Si vous collez plutôt un exemple de corps, chaque champ présent est considéré comme obligatoire et les formats sont déduits des valeurs. $ref, allOf/anyOf/oneOf et pattern ne sont pas résolus : vérifiez ces champs vous-même.
Mode d’emploi
- Collez un JSON Schema ou un vrai corps de requête, ou chargez un des exemples. La détection automatique identifie le type d’entrée ; forcez-le avec le sélecteur si besoin.
- Copiez le payload valide pour votre test du cas nominal.
- Filtrez les variantes négatives par catégorie, dépliez une variante pour l’inspecter ou la copier, ou exportez-les toutes en tableau JSON de {name, payload} pour alimenter un test piloté par les données.
FAQ : Générateur de payloads API
Qu’est-ce qu’un payload API ?
Un payload API est la donnée transportée dans le corps d’une requête ou d’une réponse, généralement du JSON pour les API REST. Par exemple, une requête POST /users peut envoyer {"name": "Asha", "email": "asha@example.com"}. La méthode, l’URL et les en-têtes décrivent la requête ; le payload en est le contenu. En test, les payloads de requête sont vos entrées et les payloads de réponse sont ce sur quoi portent vos assertions : les deux doivent respecter le contrat de l’API.
Comment générer des payloads JSON pour le test d’API ?
Partez du contrat de l’API. Collez son JSON Schema, ou un vrai corps de requête, dans ce générateur : il construit un payload valide plus une variante négative par règle (champ obligatoire manquant, mauvais type, valeur hors plage, enum invalide, etc.). Exportez-les en JSON et bouclez dessus dans vos tests. Pour des valeurs réalistes en volume, utilisez le générateur de données de test ; pour des exemples prêts à l’emploi, consultez les exemples de payloads JSON.
Que doit contenir le payload d’une requête POST ?
Exactement ce que le contrat de l’API exige pour créer la ressource : chaque champ obligatoire avec le bon type et le bon format, plus les champs optionnels utiles au scénario. Il ne doit pas contenir de champs générés par le serveur comme id ou createdAt, sauf si l’API les attend. Envoyez-le avec un en-tête Content-Type: application/json. Une création réussie renvoie généralement 201 Created avec la nouvelle ressource ou un en-tête Location ; un payload invalide doit renvoyer 400 ou 422 avec une erreur explicite.
Comment créer des payloads de test négatifs ?
Prenez un payload valide et cassez exactement une chose par test, pour qu’un échec désigne une seule règle. Variantes typiques : supprimer chaque champ obligatoire, envoyer un mauvais type ou null, dépasser d’une unité les limites de longueur ou numériques, utiliser une valeur d’enum invalide ou un e-mail mal formé, ajouter une propriété inconnue et envoyer un objet vide. Chacune doit être rejetée avec un statut 4xx et une erreur utile, jamais un 500. Ce générateur dérive automatiquement ces variantes d’un schéma.
Quels sont les formats de payload JSON courants ?
La plupart des API REST utilisent un objet JSON, souvent avec des objets imbriqués, comme un utilisateur avec une address. Autres formes courantes : des tableaux d’objets pour les opérations en masse ; des enveloppes qui placent les résultats dans des champs data et meta ; des requêtes GraphQL avec query et variables ; et les problem details de la RFC 9457 pour les erreurs, avec type, title, status et detail. Parcourez des corps de requête et de réponse réalistes dans la bibliothèque d’exemples de payloads JSON.
Puis-je générer des données de test aléatoires pour le test d’API ?
Oui. Les données aléatoires trouvent des bugs que des valeurs choisies à la main ratent, mais elles doivent rester reproductibles. Le générateur de données de test crée avec Faker des noms, e-mails, adresses, UUID, nombres et dates réalistes, et une graine (seed) fixe renvoie toujours les mêmes données, ce qui permet de rejouer un test en échec. Les bibliothèques Faker pour JavaScript et Python, ou Datafaker pour Java, font de même dans vos tests. Pour des chaînes de cas limites, utilisez le générateur de chaînes de test.
Quel code de statut les payloads négatifs doivent-ils produire ?
En général 400 Bad Request ou 422 Unprocessable Content, avec un corps d’erreur qui nomme le champ. Quelle que soit la convention documentée par l’API, elle doit être cohérente entre les endpoints, et aucune de ces variantes ne doit jamais produire un 500.
Comment utiliser le JSON exporté dans un test ?
Chargez le tableau et bouclez dessus : dans Playwright, for (const { name, payload } of variants) test(name, ...) ; dans JUnit 5, utilisez @MethodSource ou @ParameterizedTest avec une source JSON ; dans Postman, utilisez-le comme fichier de données du collection runner.
Pourquoi « Null value » (valeur null) n’est-il pas généré pour certains champs ?
Si le schéma autorise null pour un champ (type: ["string", "null"] ou null dans son enum), envoyer null est valide : ce n’est donc pas un cas négatif.