Come dovrei scrivere test automatici per un SDK senza effettuare chiamate live all'API?

Question

Come dovrei scrivere test automatici per un SDK senza effettuare chiamate live all'API?

#1 da (2 voti)
#2 da (1 voti)
#3 da (0 voti)

6

Ho sviluppato un SDK ( link ) per un'API RESTful in PHP e i miei test automatici ( esempio ) sono in realtà chiamate live contro l'API, il che è negativo per molteplici ragioni , principalmente:

ci vuole molto tempo (circa 3 ore) per i test da completare
è impossibile eseguire test simultanei perché interferiranno l'uno con l'altro

Voglio smettere di fare chiamate API live.

Ho un'idea:

cortocircuitare la richiesta prima che venga attivata
asserisci che l'URL della richiesta è corretto, in modo che, ad esempio, se passo il valore John al parametro first_name , mi aspetto che l'URI della richiesta contenga first_name=John . Inoltre, devo essere cauto sui parametri opzionali.

Tuttavia, non penso che questo sia un sostituto completo perché perdo la robustezza della risposta.

Come faccio a sapere che la richiesta è, in effetti, valida senza effettuare una chiamata dal vivo e controllare il codice di risposta o la risposta JSON?

In questo momento la libreria utilizza una lib di HTTP casuale, ma nella prossima versione principale su cui sto lavorando in questo momento, passerò a Guzzle, che esegue il test di supporto e cortocircuitando la richiesta.

Infine, puoi vedere un esempio della risposta dell'API qui: link

api sdk test-automation

posta Nino Škopac 15.09.2017 - 03:19

fonte

3 risposte

Leggi altre domande sui tag api sdk test-automation

Creazione di app C ++ con Docker: come gestire il collegamento dinamico? Quali sono le categorie più comuni per le schede Kanban e Scrum JIRA? [chiuso]

score 2 · Answer 1

Identifica ciò che vuoi veramente testare. Le regole aziendali sono sempre di primaria importanza per me. Non permetto alla logica delle regole aziendali di conoscere il mondo circostante. Ciò significa che le tue regole aziendali dovrebbero conoscere solo la tua solida risposta nella forma della struttura dati più conveniente.

Finché è tutto ciò che si aspettano, puoi testarli con il modo più opportuno per creare un esempio di quella conveniente struttura dati.

Potrebbe richiedere un codice che converta la struttura dei dati nella forma conveniente. Che controlli con esempi di entrambe le forme.

Tutto ciò che dovrebbe essere lasciato a testare è l'accesso dell'API. Qui puoi trascurare i test fino a quando l'accesso è semplice. Tuttavia, puoi prendere in giro questo problema con un server locale che replica l'API se così facendo velocizza il test.

Se almeno non hai separato ciò che deve essere testato in modo da poter lavorare senza eseguire ripetutamente i test lenti.

score 1 · Answer 2

Vuoi testare una chiamata di rete a una risorsa esterna su cui non hai controllo, giusto? Ti suggerisco di mettere quell'accesso dietro un'interfaccia o una risorsa astratta che controlli. Quindi esegui il test dell'SDK su una versione fittizia dell'API conforme al tuo SDK e restituisce il valore previsto.

Quindi, quando scrivi l'implementazione che copre l'api reale, devi solo assicurarti che l'API non trapelhi fuori dall'implementazione. In seguito, se l'API cambia o vuoi sostituirla con qualcos'altro, puoi mantenere l'interfaccia intatta e cambiare semplicemente l'implementazione, ei tuoi test sono ancora validi perché controlli l'interfaccia.

Come bonus, se vuoi aggiungere alcuni test che assicurano che l'API venga chiamata correttamente, verifica l'implementazione che hai fatto coprendo l'api senza toccare l'SDK.

Questo è qualcosa chiamato Clean Architecture / Ports and adapters e serve a rendere il codice facilmente testabile.

Alcuni materiali di lettura.

link link

score 0 · Answer 3

Suggerisco di concentrarmi su ciò che devi testare: il tuo SDK. Per testarlo è necessario sostituire le chiamate effettive all'API REST con i mock. Questi simulatori dovrebbero essere configurati per simulare le risposte per richieste diverse. Ad esempio, quando viene inviata una richiesta HTTP GET con / users / 12345, verrà restituito JSON o XML restituito dal server reale.

Usando quel server simulato dovresti essere in grado di simulare diversi scenari. Ad esempio, l'utente che non esiste deve restituire Not Found, aggiungendo un utente con lo stesso nome utente dovrebbe restituire Conflict ecc.