Informazioni sullo strumento
Fare test negativi su un endpoint significa inviare lo stesso body molte volte con esattamente una cosa sbagliata. Scrivere queste varianti a mano è lento ed è facile dimenticarne qualcuna. Incolla un JSON Schema e questo strumento ne percorre le parole chiave type, required, enum, minimum/maximum, minLength/maxLength, format e items per costruire un payload valido, poi ricava una variante per ogni regola: ogni campo obbligatorio rimosso, ogni campo con il tipo sbagliato o null, stringhe di un carattere oltre i limiti di lunghezza, numeri un passo fuori dal loro intervallo, un valore enum non valido, email e date malformate, una proprietà extra sconosciuta e un oggetto vuoto. Se invece incolli un body d’esempio, ogni campo presente viene considerato obbligatorio e i formati vengono dedotti dai valori. $ref, allOf/anyOf/oneOf e pattern non vengono risolti, quindi controlla tu quei campi.
Come si usa
- Incolla un JSON Schema o il body di una richiesta reale, oppure carica uno degli esempi. Il rilevamento automatico capisce di quale si tratta; puoi forzarlo con l’interruttore se serve.
- Copia il payload valido per il tuo test del percorso positivo (happy path).
- Filtra le varianti negative per categoria, espandi una variante per esaminarla o copiarla, oppure esportale tutte come array JSON di {name, payload} per alimentare un test data-driven.
Generatore di payload API: domande frequenti
Che cos’è un payload API?
Un payload API sono i dati trasportati nel body di una richiesta o di una risposta, di solito JSON nelle API REST. Ad esempio, una richiesta POST /users potrebbe inviare {"name": "Asha", "email": "asha@example.com"}. Metodo, URL e header descrivono la richiesta; il payload ne è il contenuto. Nel testing, i payload delle richieste sono i tuoi input e quelli delle risposte sono ciò su cui fai le asserzioni, quindi entrambi devono rispettare il contratto dell’API.
Come genero payload JSON per il testing delle API?
Parti dal contratto dell’API. Incolla il suo JSON Schema, o il body di una richiesta reale, in questo generatore: costruirà un payload valido più una variante negativa per ogni regola, come un campo obbligatorio mancante, un tipo errato, un valore fuori intervallo, un enum non valido e altro. Esportali come JSON e iterali nei tuoi test. Per valori realistici in grande quantità usa il generatore di dati di test; per esempi già pronti consulta i payload JSON di esempio.
Che cosa deve contenere il payload di una richiesta POST?
Esattamente ciò che il contratto dell’API richiede per creare la risorsa: ogni campo obbligatorio con il tipo e il formato corretti, più i campi opzionali rilevanti per lo scenario. Non deve contenere campi generati dal server come id o createdAt, a meno che l’API non li preveda. Invialo con l’header Content-Type: application/json. Una creazione riuscita di solito restituisce 201 Created con la nuova risorsa o un header Location; un payload non valido dovrebbe restituire 400 o 422 con un errore chiaro.
Come creo payload per i test negativi?
Prendi un payload valido e rompi esattamente una cosa per test, così un fallimento punta a una sola regola. Varianti tipiche: rimuovere ciascun campo obbligatorio, inviare il tipo sbagliato o null, superare di uno i limiti di lunghezza o numerici, usare un valore enum non valido o un’email malformata, aggiungere una proprietà sconosciuta e inviare un oggetto vuoto. Ognuna deve essere rifiutata con uno status 4xx e un errore utile, mai con un 500. Questo generatore ricava automaticamente queste varianti da uno schema.
Quali sono i formati di payload JSON più comuni?
La maggior parte delle API REST usa un oggetto JSON, spesso con oggetti annidati come un utente con un address. Altre forme comuni sono gli array di oggetti per le operazioni bulk, gli envelope che racchiudono i risultati nei campi data e meta, le richieste GraphQL con query e variables e i problem details della RFC 9457 per gli errori, con type, title, status e detail. Sfoglia body di richiesta e risposta realistici nella libreria di payload JSON di esempio.
Posso generare dati di test casuali per il testing delle API?
Sì. I dati randomizzati trovano bug che i valori scelti a mano non vedono, ma devono essere riproducibili. Il generatore di dati di test crea con Faker nomi, email, indirizzi, UUID, numeri e date realistici, e un seed fisso restituisce ogni volta gli stessi dati, così un test fallito può essere rieseguito. Le librerie Faker per JavaScript e Python, o Datafaker per Java, fanno lo stesso dentro i tuoi test. Per stringhe da casi limite usa il generatore di stringhe di test.
Quale status code dovrebbero produrre i payload negativi?
Di solito 400 Bad Request o 422 Unprocessable Content, con un body di errore che indica il campo. Qualunque cosa documenti l’API, deve essere coerente tra gli endpoint, e nessuna di queste varianti dovrebbe mai produrre un 500.
Come uso il JSON esportato in un test?
Carica l’array e iteralo: in Playwright, for (const { name, payload } of variants) test(name, ...); in JUnit 5 usa un @MethodSource o un @ParameterizedTest con una sorgente JSON; in Postman usalo come file di dati del collection runner.
Perché per alcuni campi non viene generato “Null value”?
Se lo schema ammette null per un campo (type: ["string", "null"] oppure null nel suo enum), inviare null è valido, quindi non è un caso negativo.