Ecco come esegue il test delle API esterne in elisir con bypass

$config[ads_kvadrat] not found

Hard Reset Surf onn tablet from walmart // How to remove password, pattern, Pin

Hard Reset Surf onn tablet from walmart // How to remove password, pattern, Pin

Sommario:

Anonim

Diamo priorità ai principi dell'architettura orientata ai servizi a Inverso. Ciò significa che abbiamo componenti piccoli e manutenibili con responsabilità chiaramente definite. Comunicano l'uno con l'altro (principalmente), tramite Representational State Transfer o REST, API.

Ciò fornisce flessibilità e ci è stato utile con l'eccezione di un aspetto importante: Test. Durante i test, si dovrebbe evitare:

  • Dipendenza da servizi esterni in esecuzione sulla stessa macchina.
  • Test lenti.

Poiché le applicazioni si affidano intrinsecamente a servizi esterni, è fondamentale disporre di una strategia di test per tali dipendenze.

Recentemente abbiamo iniziato a utilizzare Bypass e spiegherò come siamo arrivati ​​lì e specificamente come lo stiamo usando.

Il passato

Metodi di simulazione e restituire alcuni dati di esempio come questo:

Era (e credo che lo sia ancora) la "strada da percorrere" nel mondo di Ruby / Rails. Sfortunatamente, ciò favorisce un cattivo comportamento come meglio spiegato da José Valim.

Abbiamo quindi iniziato a utilizzare ExVCR, che è una grande libreria, ma ha degli svantaggi simili a mock / stub: incoraggia la pigrizia e non favorisce la separazione delle preoccupazioni che sono fondamentali per le API ben definite. ExVCR consente di "registrare" e "riprodurre" dati in tempo reale. È molto facile da integrare (comprese alcune righe nel test e tutto il resto è curato). Ma idealmente devi pensare alle dipendenze esterne nei test, non astrarli. Potrebbe essere comunque una scelta valida per gli scenari in cui il comportamento degli endpoint dovrebbe essere testato con un sovraccarico minimo (lo usiamo per testare le chiamate ai servizi AWS di Amazon come S3).

Inserisci adattatori

Gli adattatori funzionano alla grande e promuovono la deliberazione attorno ai contratti API e ai confini di comunicazione chiaramente definiti. Usiamo ancora questo approccio, specialmente quando l'adattatore è più complesso (come un socket JSON-RPC).

Ecco come potrebbe apparire un adattatore:

Ma per gli endpoint HTTP semplici, gli adattatori sembrano un sacco di lavoro e hanno un grosso svantaggio: lasciano le librerie che consumano dall'equazione di test. Se qualcosa nelle librerie HTTP o JSON cambia, i test non lo cattureranno. La quantità di codice critico per la produzione che non è stata testata da questo approccio è inaccettabile.

Il presente e il futuro

Bypass ci consente di avviare un server Web molto semplice in test che simulino i servizi esterni che utilizziamo.

Ora possiamo testare l'intero stack, inclusa la libreria HTTP, la libreria di codifica / decodifica JSON e i meccanismi di autenticazione. Il README Bypass è ben scritto, quindi risparmierò i dettagli di implementazione. Tuttavia, modifichiamo leggermente il modo in cui lo usiamo per mantenere i test concisi e leggibili:

Prima di tutto, a volte vogliamo chiamare su Facebook quando i test vengono eseguiti come una suite di integrazione completa. Lo facciamo in modo irregolare per garantire che l'API di Facebook funzioni ancora secondo le nostre aspettative. Aggiunta --include integrazione a test di miscelazione non simula l'API ma, al contrario, chiama al servizio esterno (righe 5, 7).

Siamo espliciti quando simuliamo richieste a servizi esterni in modo che ogni test che utilizza Bypass debba avere il @tag facebook_bypass (linea 7).

Infine, il handle_fb funzione (righe 30-39) viene chiamata (dato che il request_path partite). Mi piace la corrispondenza nel capo funzione in quanto rende esplicito il percorso a cui stiamo reagendo e ci consente di definire diverse funzioni per percorsi diversi.

Quindi Bypass viene eseguito solo sui test contrassegnati con @tag: bypass e quando non stiamo eseguendo la nostra suite di integrazione. Un'altra cosa che facciamo mentre impostiamo Bypass sta permettendo al tag di passare un id di pagina (righe 8, 20). Quindi ecco come un test che usa Bypass appare in tutta la sua gloria:

Come puoi vedere, il facebook_bypass il tag rende esplicito che stiamo simulando l'API (a meno che non ci troviamo nella modalità di integrazione). Ci consente di passare le informazioni all'API simulata ed è molto facile riutilizzare la stessa configurazione di bypass per diversi test.

Spero che questo ti aiuti a testare le API esterne. Puoi trovarmi su Twitter (vedi sotto) se hai ulteriori domande.

$config[ads_kvadrat] not found