Menu

Tutorial su Wiremock: Introduzione a Wiremock

wiremock tutorial introduction wiremock

Prova Il Nostro Strumento Per Eliminare I Problemi

Questo video tutorial introduttivo spiegherà le caratteristiche di Wiremock e come eseguire Wiremock come server autonomo e come parte dei test JUnit:

In questo tutorial, tratteremo i concetti e i dettagli di base sullo strumento Wiremock. Può essere utilizzato come server HTTP autonomo e all'interno dei test JUnit secondo i requisiti.

Questo è uno strumento molto utilizzato in quanto è open source e ha una grande comunità di collaboratori. Rientra nella categoria degli strumenti di virtualizzazione dei servizi.

Introduzione allo strumento Wiremock

Cosa imparerai:

Cos'è Wiremock?

In termini semplici, Wiremock è una configurazione beffarda per i test di integrazione. È semplicemente un server fittizio altamente configurabile per restituire una risposta prevista per una determinata richiesta.

È ampiamente utilizzato durante lo sviluppo e, cosa ancora più importante, durante i test di integrazione mentre un sistema o un servizio parla con una o più dipendenze / servizi interni o esterni.

Cerchiamo di capire di più sui test di integrazione in generale e di capire come Wiremock può aiutare a superare queste sfide e semplificarci la vita.

Generalmente, quando arriva la parola integrazione, ciò che ci colpisce è un'integrazione end-to-end tra 2 sistemi di comunicazione. Ora, guardiamolo dal punto di vista di un'applicazione sotto test che utilizza un servizio esterno per portare a termine il lavoro.

Per esempio, supponiamo di creare un'applicazione per il sistema di viaggio o di biglietteria online e di avere un modulo per il controllo dello stato del PNR, che colpisce un'API esterna fornita da Indian Railways.

Ora, come possiamo testare l'integrazione della nostra applicazione con le API esterne?

Ci sono 2 modi per farlo:

  • Primo, è l'approccio di test unitario, in cui blocciamo l'interfaccia fornita (o creata internamente) in modo che il nostro sistema test / convalidi la risposta bloccata o falsa anche prima di colpire l'API esterna. Questo non è altro che uno unit test che cerca di deridere una dipendenza esterna.
  • Secondo sta testando con un ambiente di test (o l'effettivo ambiente di produzione) delle dipendenze esterne. Tuttavia, ci sono diverse sfide con questo approccio come menzionato di seguito:
    • I sistemi API esterni potrebbero non essere sempre disponibili. Vale a dire, siamo fortemente dipendenti o dipendenti da sistemi esterni e qualsiasi tempo di inattività avrà un impatto sui nostri test e indirettamente sul processo di sviluppo / rilascio.
    • In secondo luogo, le API esterne potrebbero o non potrebbero avere un ambiente di test. Per esempio, un'API per il controllo dello stato del PNR potrebbe sempre richiedere numeri PNR reali per recuperare e restituire le risposte.
    • Molte volte, ci sono dei costi per raggiungere un'API. Per esempio, supponiamo che l'API di controllo PNR addebiti Rs 100 per ogni 1000 richieste. Poiché i test di integrazione vengono solitamente eseguiti durante ogni regressione (e la maggior parte del tempo con ogni commit), potrebbe non essere una soluzione conveniente per raggiungere tale API che ci costa anche per scopi di test.
    • Non è possibile configurare un'API esterna per restituire la risposta desiderata. Anche se possibile, dovrai creare molti dati di test per garantire risposte diverse per diversi input di richiesta.
      Per esempio, vuoi testare scenari di errore come se un'API restituisse codici di stato diversi per diversi tipi di dati. Ora, poiché la risposta non è sotto il nostro controllo, avremo bisogno di creare più set di dati per convalidare diversi possibili scenari o risultati.

Comprendiamo questi concetti con l'aiuto del diagramma seguente.

Qui stiamo confrontando entrambi gli approcci del test di integrazione, ovvero senza un server fittizio utilizzando un'implementazione effettiva della dipendenza esterna e utilizzando il server fittizio (Wiremock) che deride le risposte alle richieste ricevute per la dipendenza.

In quest'ultimo caso, riduce notevolmente la dipendenza e la dipendenza dall'effettiva implementazione della dipendenza e offre molte funzionalità di configurazione senza compromettere la qualità e le tempistiche di consegna.

Concetti di Wiremock

Come risponde Wiremock a una determinata richiesta?

Come sappiamo, Wiremock è un server Mock programmatico, il modo in cui risponde a una determinata richiesta è archiviando tutte le mappature pertinenti (o risposte simulate) in una cartella denominata 'mappature'

Esiste un componente di corrispondenza di Wiremock che abbina le richieste in arrivo alle mappature memorizzate e se viene restituita una corrispondenza riuscita, la prima corrispondenza di questo tipo viene restituita come risposta per la richiesta data.

Nel caso tu stia utilizzando la versione standalone di Wiremock, una volta eseguito il server Wiremock, vedrai la cartella dei mapping che verrà creata nella directory di installazione / jar di Wiremock.

Tutorial video: Introduzione allo strumento Wiremock

come scrivere script di test di automazione

Come utilizzare Wiremock?

Vediamo ora come possiamo utilizzare questo strumento con i nostri test di integrazione.

Può essere utilizzato nei seguenti modi.

Un server Wiremock autonomo

Come server autonomo, puoi semplicemente creare una semplice applicazione Java con dipendenza Maven / Gradle per Wiremock e mantenerla come processo in esecuzione.

Questa è una buona alternativa quando vuoi ospitare il tuo server standalone su qualche macchina e usarlo come un singolo server mocking per l'intero progetto o team. In modalità standalone, questo strumento può essere eseguito anche scaricando il jar standalone disponibile Qui e basta eseguire il barattolo.

Per esempio, supponi di voler distribuire la tua istanza standalone di Wiremock su un server su cloud o su un server in sede, quindi puoi semplicemente eseguire questo jar e utilizzare l'IP di sistema per usarlo come servizio ospitato.

Vediamone alcuni passaggi per eseguirlo in modalità autonoma (e configurare cose diverse come porte, cartelle di mappatura, ecc.)

# 1) Esegui il jar Wiremock dal terminale (o dal prompt dei comandi per gli utenti Windows) come qualsiasi altro file JAR (dalla directory di installazione del jar Wiremock).

java -jar wiremock-standalone-2.25.1.jar

#Due) Per impostazione predefinita, Wiremock viene eseguito su localhost: 8080 (se la porta è gratuita, il comando precedente avvierà il server Wiremock in modalità autonoma) e vedrai l'output come di seguito.

Wiremock viene eseguito su localhost

# 3) Ora, una volta avviato il server, puoi visitare qualsiasi URL su localhost: 8080

Per esempio, http: // localhost: 8080 / get / user / 1 - Poiché attualmente non ci sono mock in fase di impostazione, riceverai una risposta come mostrato di seguito.

Risposta di Wiremock

# 4) Ora proviamo a impostare un semplice stub / mock per questo URL e prova a reimpostare l'URL. Verificheremo quindi che colpire lo stesso URL ora restituisce la risposta derisa o bloccata.

curl -X POST --data '{ 'request': { 'url': '/get/user/1', 'method': 'GET' }, 'response': { 'status': 200, 'body': 'Here it is! ' }}' http://localhost:8080/__admin/mappings/new

Proviamo prima a capire questa richiesta CURL:

  • Stiamo effettuando una richiesta CURL POST a http: // localhost: 8080 / __ admin / mappings / new - Ora questa è la posizione in cui verranno archiviate tutte le mappature per il server Wiremock che abbiamo eseguito / avviato tramite il file JAR.
  • Nella richiesta Curl, stiamo definendo parametri di richiesta come - URL e metodo di richiesta insieme al corpo della risposta nella sezione 'risposta'. Ciò implica semplicemente che ogni volta che una richiesta GET arriva con URL / get / user / 1, rispondi con il corpo della risposta specificato.

# 5) Una volta impostata la risposta bloccata (con l'aiuto della richiesta di curl sopra), possiamo provare a premere l'URL e vedere se stiamo ottenendo una risposta bloccata dal Wiremock.

Proviamo a premere questo URL nel browser: http: // localhost: 8080 / get / user / 1

Se la mappatura è stata impostata correttamente, dovresti ricevere una risposta come mostrato di seguito:

la mappatura è stata impostata correttamente

Insieme ai test JUnit come configurazione della regola JUnit

Il server Wiremock può essere utilizzato con i test JUnit come impostazione di una regola JUnit. Con questo, JUnit si prende cura del ciclo di vita di Wiremock, ovvero Wiremock si avvia e si arresta.

come eseguo i file swf

Viene utilizzato principalmente nelle configurazioni in cui desideri avviare e arrestare il server dopo ogni test.

Questo ha i suoi vantaggi di essere isolato e ha un alto grado di configurabilità rispetto a una configurazione autonoma in cui più persone possono finire per utilizzare lo stesso server e scavalcare le risposte stub l'una dell'altra.

Vediamo un esempio funzionante di questo approccio:

# 1) Crea una regola JUnit per il server Wiremock. Questo passaggio è essenzialmente come un passaggio di configurazione del test in cui stiamo dicendo al runner JUnit di istanziare il server Wiremock prima di ogni test e arrestare il server dopo ogni test.

Ciò significa anche che JUnit runner si prenderà cura di avviare e arrestare il server Wiremock, senza farlo esplicitamente.

@Rule public WireMockRule wm = new WireMockRule(wireMockConfig().port(8080));

#Due) Ora scriveremo il nostro test in cui creeremo prima il nostro client (usando okHttp) per eseguire le richieste sull'endpoint desiderato.

// execute request through http client OkHttpClient client = new OkHttpClient(); Request request = new Request.Builder() .url('http://localhost:8080/test/abc') .get() .build();

# 3) Ma, puoi notare qui, che non abbiamo ancora impostato alcuno stub da restituire per la nostra istanza di Wiremock. cioè il client sopra richiederà un URL http: // localhost: 8080 / test / abc che non ha alcuno stub configurato. In questo caso, il server Wiremock restituirà un 404 nessun contenuto.

# 4) Ora per impostare uno stub per l'URL sopra per la nostra istanza del server Wiremock, dovremo chiamare i metodi statici dello stub di Wiremock come mostrato di seguito.

private void configureStubs() { configureFor('localhost', 8080); stubFor(get(urlEqualTo('/test/abc')) .willReturn(aResponse().withBody('Test success!'))); }

Qui puoi vedere che abbiamo utilizzato un paio di metodi statici come configureFor, stubFor, ecc. Tutti questi metodi fanno parte della libreria Java di Wiremock. (Esamineremo questi metodi in dettaglio nel nostro prossimo tutorial / sezioni)

# 5) Ora, con il passaggio di configurazione completato, possiamo semplicemente eseguire la richiesta tramite il client e convalidare la risposta (a seconda di ciò che è configurato per il ritorno dello stub tramite Wiremock)

Per riassumere, ecco come apparirebbe l'intero codice di esempio:

public class WiremockJunitTest { @Rule public WireMockRule wm = new WireMockRule(wireMockConfig().port(8080)); @Test public void assertWiremockSetup() throws IOException { // Arrange - setup wiremock stubs configureStubs(); // execute request through the http client OkHttpClient client = new OkHttpClient(); Request request = new Request.Builder() .url('http://localhost:8080/test/abc') .get() .build(); // Act - call the endpoint Response response = client.newCall(request).execute(); // Assert - verify the response assertEquals('Test success!', response.body().string()); verify(exactly(1),getRequestedFor(urlEqualTo('/test/abc'))); } // configure stubs for wiremock private void configureStubs() { configureFor('localhost', 8080); stubFor(get(urlEqualTo('/test/abc')) .willReturn(aResponse().withBody('Test success!'))); } }

Dipendenze richieste

È disponibile come:

  • Un JAR autonomo contenente solo la dipendenza Wiremock.
  • Un barattolo grasso contenente Wiremock e tutte le sue dipendenze.

Entrambi i gusti sono disponibili come dipendenze Gradle e Maven. Maggiori dettagli sono disponibili nel repository ufficiale Maven Qui

Esercitazione video: Wiremock con JUnit Test

Conclusione

In questo tutorial, abbiamo esaminato le funzionalità di base di Wiremock e abbiamo visto come può essere eseguito come server autonomo e come parte dei test JUnit utilizzando le regole JUnit.

Abbiamo anche accennato allo stubbing in breve e lo tratteremo in dettaglio nel nostro prossimo tutorial.

PROSSIMO Tutorial

Lettura consigliata

^