Come simulare un'API REST?

Sto lavorando a un nuovo progetto che interrogherà i dati da un'API REST di terze parti. Questo è per un feed di dati sportivi in ​​tempo reale, quindi il feed funziona solo quando si sta effettivamente svolgendo un gioco.

Sebbene la terza parte fornisca una buona documentazione (XSD, ecc.), Non hanno modo di simulare un gioco in corso, quindi per testare il codice che ho scritto contro questa API dovrei aspettare che accada un gioco vero e proprio.

La mia unica risorsa è scrivere codice per simulare un gioco da solo, ma sembra un sacco di lavoro. Come affronteresti questo?

Questo è il caso d'uso perfetto per un oggetto simulato . Ci sono librerie beffardo per ogni lingua popolare. Si desidera deridere l'oggetto che fornisce le risposte del servizio REST per restituire i dati di test. È possibile generare manualmente i dati del test o raccoglierli dalle chiamate precedenti al sistema live.

Aspetta che accada un gioco. Cattura ogni evento dal feed. Scrivi un simulatore che riproduca gli eventi nei momenti appropriati. Voilà, hai un simulatore di feed con dati reali.

Consiglio di scrivere il tuo simulatore. Puoi usarlo per testare tutti i tipi di scenari;

• Il server accetta la connessione ma non risponde
• Timeout del server
• Server rispedire risposta immondizia ecc ...

Quando l'ho fatto in passato, ho usato valori "speciali" nei messaggi di richiesta per chiedere al simulatore di fare ciò di cui ho bisogno. Ciò consente anche di eseguire test end-to-end senza uscire dall'ambiente di sviluppo.

Modifica: ad esempio, se il progetto inoltra XML a un servizio di terze parti, la richiesta potrebbe includere ad es <value>50.00</value>. Il simulatore può essere codificato (o, meglio, configurato) in modo che 50,00 => esploda, 60,00 => immondizia, 70,00 => chiudi la connessione e così via. L'idea è che il comportamento del simulatore dipende dal suo input, che controlli in ogni caso di test.

Considerando che probabilmente il bookmaker fornisce alcuni dati di esempio (e che possono essere salvati durante la fase di integrazione), il mio consiglio è di organizzare questi feed in questo modo:

• Elenco degli eventi
• Aggiornamenti per eventi programmati
• Aggiornamenti delle quote
• risultati

Probabilmente il fornitore offre 2 tipi di aggiornamenti: Push (POST) e Pull (GET).

A questo punto dovresti

1. Crea un server semplice che gestisca solo le richieste GET, in modo che i tuoi programmatori possano elaborare algoritmi.
2. Crea un'automazione per gestire l'invio delle stesse informazioni e può quindi stressare il tuo sistema.

Gestire lo sviluppo e i test

Senza entrare nei dettagli della tecnologia da utilizzare, si ottiene un mini-server , che risponde solo a 4 URL (o quelli necessari a seconda di ciò che offre il provider) e un servizio mini-push .

Una cosa molto buona da tenere a mente quando si lavora con il "mini-server", sono i gestori del protocollo HTTP. Creare un server sulla porta 80 è molto semplice e risolve il problema. Devi essere sicuro di inserire tutte le informazioni nelle risposte OTTENERE mentre il provider fa (questo eviterà problemi quando messo in produzione).

Personalmente farei un semplice server Perl o lo stesso ma con Nodejs. Per quanto riguarda l'iniezione di dati, sarà sufficiente un timer, che invoca un browser offline ( CURL , WGET )

Ho simulato l'API REST usando la combinazione di cucumberjs, phantomjs con l'impostazione del server proxy su 127.0.0.1 e l'aggancio di un processo node.js con http-proxye nocklì. CucumberJS non è la parte importante, è possibile scrivere lo scenario di test in ogni modo, il resto è la chiave della simulazione. È in grado di deridere semplicemente per corrispondenza-richiesta-ritorno-dati, ma puoi anche filtrare per motivi e agganciare la funzione di richiamata per produrre una risposta, in modo da poter simulare a qualsiasi livello di granularità di cui hai bisogno (in conclusione estrema con un server demo completo, ma puoi farlo in modo incrementale).

Funziona bene:

1. Phantomjs richiede un URI.
2. La richiesta va al server proxy su 127.0.0.1:port.
3. Il processo node.js lo inoltra in modo trasparente inoltra tramite http-proxy. Quindi funziona qualsiasi caricamento "normale" (pagine, immagini).
4. Se si sceglie di intercettare alcune richieste (principalmente API) utilizzate nockper esso.

Nel mio scenario, l'ho combinato con i test js di cetriolo nello stesso processo, quindi è andato come:

1. Esecuzioni di test.
2. Imposta il nockderisione HTTP per lo scenario testato.
3. Carica una pagina in phantomjs tramite il protocollo Selenium.

Il resto è come mostrato in precedenza in questo paragrafo (vale a dire, è un po 'un ciclo, io come test runner incarico a phantomjs di caricare una pagina, che inoltra tutte le richieste a me e le inoltro alla rete; o intercetto se è l'API testata).