Come simulare un'API REST?

Questo è il caso d'uso perfetto per un oggetto fittizio . Ci sono librerie di derisione per ogni lingua popolare. Si desidera simulare l'oggetto che fornisce le risposte del servizio REST per restituire i dati del test. Puoi generare manualmente i dati del test o raccoglierlo dalle chiamate precedenti al sistema live.

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

Raccomando 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
• Il server restituisce la risposta spazzatura ecc ...

Quando ho fatto questo in passato, ho usato valori "speciali" nei messaggi di richiesta per richiedere 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 tuo progetto invia XML a un servizio di terze parti, la richiesta potrebbe includere, ad es. %codice%. Il simulatore può essere codificato (o, meglio, configurato) in modo che 50.00 = > esplodere, 60.00 = > garbage, 70.00 = > connessione chiusa e così via. L'idea è che il comportamento del simulatore dipende dal suo input, che controlli in ogni caso di test.

Ho simulato l'API REST utilizzando 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-proxy e nock lì. CucumberJS non è la parte importante, puoi scrivere lo scenario di test in qualsiasi modo, il resto è la chiave della simulazione. È in grado di simulare semplicemente match-request-return-data, ma puoi anche filtrare per pattern e richiamare la funzione callback per produrre una risposta, in modo da poter simulare a qualsiasi livello di granularità di cui hai bisogno (in estremo termina 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 tuo processo node.js lo inoltra in modo trasparente usando http-proxy . Quindi qualsiasi caricamento "normale" (pagine, immagini) funziona.
4. Se scegli di intercettare alcune richieste (API, principalmente) utilizzi nock per questo.

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

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

Il resto è come mostrato in precedenza in questo paragrafo (cioè, è un po 'un ciclo, io come runner di test istruisco phantomjs per caricare una pagina, che inoltra tutte le richieste a me, e le inoltro alla rete oppure intercettali se è l'API testata.

Considerando che probabilmente il bookmaker fornisce alcuni dati di esempio (e questo può essere salvato 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 provider 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 programmatori possano elaborare algoritmi.
2. Crea un'automazione per gestire gli invii delle stesse informazioni e può quindi mettere in risalto il tuo sistema.

Gestisci lo sviluppo e i test

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

A very good thing to keep in mind when working with the "mini-server", are the handlers of the HTTP protocol. Create a server on port 80 is very simple, and solves the problem. You have to be sure to inject all the information in the responses GET as the provider makes (this will avoid problems when put into production).

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