Testare un’API REST in 5 minuti

Obiettivo: partire da una specifica OpenAPI e arrivare a un test automatizzato che verifichi un percorso completo.

1. Importare la specifica (30 secondi)

File ▸ Importa (Ctrl+I), poi l’URL del proprio openapi.json.

Restorm costruisce l’albero completo: una cartella per etichetta, una richiesta per operazione, i parametri tipizzati, la documentazione e gli header di autenticazione precablati con le loro variabili.

L’albero prodotto dall’importazione OpenAPI, pronto all’uso: una cartella per etichetta (pet, store, user) e una richiesta precompilata per operazione, accanto alla sotto-scheda iniziale della cartella di variabili

Se l’API non ha una specifica, basta incollare un comando curl — si veda Importare comandi cURL.

2. Compilare l’ambiente (1 minuto)

Aprire la cartella di variabili creata dall’importazione. L’URL di base è già lì; resta da completare la variabile di autenticazione che l’importazione ha preparato.

Si può creare un secondo ambiente se si verificano più destinazioni — il selettore della smartbar commuta l’intera cartella in un colpo solo.

3. Inviare una prima chiamata (30 secondi)

Aprire una richiesta e fare clic su Send. La risposta compare: stato, tempo, header, corpo in un visualizzatore richiudibile.

Se è stato dimenticato qualcosa, lo dice il valore risolto mostrato sotto il campo URL.

4. Costruire lo scenario (2 minuti)

Clic destro ▸ Aggiungi ▸ Scenario. Il percorso «crea, rileggi, elimina»:

Richiesta HTTP «POST /clients»
     └─response──► Assert (eq, 201)
              └─► Definisci variabile «clientId»   ◄── selettore body.id

Richiesta HTTP «GET /clients/{id}»
     └─response──► Assert (eq, 200)
              └─► Validazione dello schema (il JSON Schema del cliente)

Richiesta HTTP «DELETE /clients/{id}»
     └─response──► Assert (eq, 204)

Le tre richieste usano {{clientId}} nel proprio URL: la variabile di run impostata al primo passaggio viene letta dai successivi.

Si concatenano cablando la porta done di ogni asserzione sulla porta in della richiesta successiva — è ciò che garantisce l’ordine.

5. Verificare (30 secondi)

Fare clic su Riproduci. Il log si riempie; conviene aggiungere un’azione Log dopo ogni passaggio per tracciare ciò che conta.

Collegando un’azione Throw all’uscita else delle asserzioni critiche si ottiene ciò che farà fallire il job di CI.

6. Automatizzarlo (30 secondi)

RESTORM_TOKEN=rstk_… restorm \
  --open ./api.restorm \
  --run "Parcours client" \
  --headless \
  --out run.log

Codice di uscita 0 se tutto passa, 1 altrimenti. Si veda Esecuzione headless e CI per gli esempi GitHub Actions e GitLab CI.