Menu

Tutoriel Wiremock: Introduction à Wiremock

wiremock tutorial introduction wiremock

Essayez Notre Instrument Pour Éliminer Les Problèmes

Ce didacticiel vidéo d'introduction expliquera les fonctionnalités de Wiremock et comment exécuter Wiremock en tant que serveur autonome et dans le cadre des tests JUnit:

Dans ce didacticiel, nous couvrirons les concepts de base et les détails de l'outil Wiremock. Il peut être utilisé comme serveur HTTP autonome ainsi que dans les tests JUnit selon les exigences.

C'est un outil très utilisé car il est open-source et possède une grande communauté de contributeurs. Il entre dans la catégorie des outils de virtualisation de service.

Présentation de l

Ce que vous apprendrez:

Qu'est-ce que Wiremock?

En termes simples, Wiremock est une configuration moqueuse pour les tests d'intégration. Il s’agit simplement d’un serveur fictif hautement configurable pour renvoyer une réponse attendue pour une demande donnée.

Il est largement utilisé pendant le développement et plus important encore pendant les tests d'intégration pendant qu'un système ou un service communique avec une ou plusieurs dépendances / services externes ou internes.

Essayons de mieux comprendre les tests d'intégration en général et apprenons comment Wiremock peut nous aider à surmonter ces défis et à nous faciliter la vie.

Généralement, quand vient le mot intégration, ce qui nous frappe, c'est une intégration de bout en bout entre 2 systèmes communicants. Voyons maintenant cela du point de vue d'une application en cours de test qui utilise un service externe pour faire le travail.

Par exemple, supposons que nous construisions une application pour un système de voyage ou de billetterie en ligne et que nous disposions d'un module de vérification de l'état des PNR, qui accède à une API externe fournie par Indian Railways.

Maintenant, comment pouvons-nous tester l'intégration de notre application avec les API externes?

Il existe 2 façons de procéder:

  • Premier, est l'approche de test unitaire, où nous stubons l'interface fournie (ou créée en interne) afin que notre système teste / valide la réponse tronquée ou fausse avant même de toucher l'API externe. Ce n'est rien d'autre qu'un test unitaire essayant de simuler une dépendance externe.
  • Deuxième teste avec un environnement de test (ou l'environnement de production réel) des dépendances externes. Cependant, cette approche présente plusieurs défis, tels que mentionnés ci-dessous:
    • Les systèmes d'API externes peuvent ne pas être toujours disponibles. c'est-à-dire que nous sommes fortement dépendants ou dépendants de systèmes externes et tout temps d'arrêt aura un impact sur nos tests et indirectement sur le processus de développement / publication.
    • Deuxièmement, les API externes peuvent ou non avoir un environnement de test. Par exemple, une API de vérification de l'état PNR peut toujours nécessiter de vrais numéros PNR pour récupérer et renvoyer les réponses.
    • Souvent, il y a des coûts liés à l'utilisation d'une API. Par exemple, Supposons que l'API de contrôle PNR facture Rs 100 pour 1000 demandes. Comme les tests d'intégration sont généralement exécutés lors de chaque régression (et la plupart du temps avec chaque commit), ce n'est peut-être pas une solution rentable pour atteindre une telle API qui nous coûte même à des fins de test.
    • Une API externe ne peut pas être configurée pour renvoyer la réponse souhaitée. Même si possible, vous devrez créer de nombreuses données de test pour garantir des réponses différentes pour différentes entrées de demande.
      Par exemple, vous souhaitez tester des scénarios d'erreur comme une API renvoie différents codes d'état pour différents types de données. Maintenant que la réponse n'est pas sous notre contrôle, nous devrons créer plusieurs ensembles de données pour valider différents scénarios ou résultats possibles.

Comprenons ces concepts à l’aide du diagramme ci-dessous.

Ici, nous comparons les deux approches de test d'intégration, c'est-à-dire sans serveur fictif en utilisant une implémentation réelle de la dépendance externe et en utilisant le serveur fictif (Wiremock) qui se moque des réponses aux demandes reçues pour la dépendance.

Dans ce dernier cas, cela réduit considérablement la dépendance et la dépendance vis-à-vis de la mise en œuvre réelle de la dépendance et offre de nombreuses capacités de configuration sans compromettre la qualité et les délais de livraison.

Concepts de Wiremock

Comment Wiremock répond-il à une demande donnée?

Comme nous le savons, Wiremock est un serveur Mock programmatique, la façon dont il répond à une demande donnée consiste à stocker tous les mappages pertinents (ou réponses simulées) dans un dossier nommé «mappings»

Il existe un composant de mise en correspondance de Wiremock qui fait correspondre les demandes entrantes aux mappages stockés et si une correspondance réussie est renvoyée, la première de ces correspondances est renvoyée en tant que réponse à la demande donnée.

Si vous utilisez la version autonome de Wiremock, une fois que vous exécutez le serveur Wiremock, vous verrez le dossier mappings qui sera créé dans le répertoire d’emplacement Wiremock install / jar.

Tutoriel vidéo: Introduction à l'outil Wiremock

quel processus nécessite des versions et des tests automatisés pour vérifier le logiciel pendant le développement

Comment utiliser Wiremock?

Voyons maintenant comment nous pouvons utiliser cet outil avec nos tests d'intégration.

Il peut être utilisé des manières suivantes.

Un serveur Wiremock autonome

En tant que serveur autonome, vous pouvez simplement créer une application Java simple avec une dépendance Maven / Gradle pour Wiremock et la conserver en tant que processus en cours d'exécution.

C'est une bonne alternative lorsque vous souhaitez héberger votre serveur autonome sur une machine et l'utiliser comme serveur de simulation unique pour l'ensemble du projet ou de l'équipe. En mode autonome, cet outil peut également être exécuté, en téléchargeant le fichier jar autonome disponible Ici et exécutez simplement le pot.

Par exemple, supposons que vous souhaitiez déployer votre instance autonome Wiremock sur un serveur sur le cloud ou sur un serveur sur site, vous pouvez simplement exécuter ce fichier jar et utiliser l'adresse IP du système pour l'utiliser en tant que service hébergé.

Voyons quelques-uns étapes pour l'exécuter en mode autonome (et configurer différentes choses comme les ports, les dossiers de mappage, etc.)

#1) Exécutez le fichier JAR Wiremock à partir du terminal (ou de l'invite de commande pour les utilisateurs Windows) comme n'importe quel autre fichier JAR (à partir du répertoire d'installation du fichier JAR Wiremock).

java -jar wiremock-standalone-2.25.1.jar

#deux) Par défaut, Wiremock s'exécute sur localhost: 8080 (si le port est libre d'utilisation, la commande ci-dessus démarrera le serveur Wiremock en mode autonome) et vous verrez la sortie comme ci-dessous.

Wiremock fonctionne sur localhost

# 3) Désormais, une fois le serveur démarré, vous pouvez visiter n'importe quelle URL sur localhost: 8080

Par exemple, http: // localhost: 8080 / get / user / 1 - Comme il n'y a actuellement aucune simulation définie, vous obtiendrez une réponse comme indiqué ci-dessous.

Réponse de Wiremock

# 4) Essayons maintenant de configurer un simple stub / maquette pour cette URL et réessayez de la renvoyer. Nous validerons ensuite que frapper la même URL renvoie maintenant la réponse simulée ou stubbée.

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

Essayons d'abord de comprendre cette requête CURL:

  • Nous faisons une requête CURL POST à ​​http: // localhost: 8080 / __ admin / mappings / new - Il s'agit maintenant de l'emplacement où tous les mappages seront stockés pour le serveur Wiremock que nous avons exécuté / démarré via le fichier JAR.
  • Dans la requête Curl, nous définissons des paramètres de requête tels que - URL et méthode de requête avec le corps de la réponse dans la section «réponse». Cela implique simplement que chaque fois qu'une requête GET arrive avec URL / get / user / 1, répondez avec le corps de réponse spécifié.

# 5) Une fois que la réponse stubbed est définie (avec l'aide de la requête curl ci-dessus), nous pouvons essayer de frapper l'URL et voir si nous récupérons la réponse stubbed du Wiremock.

Essayons de frapper cette URL dans le navigateur - http: // localhost: 8080 / get / user / 1

Si le mappage a été correctement défini, vous devriez obtenir une réponse comme indiqué ci-dessous:

le mappage a été défini avec succès

Avec les tests JUnit en tant que configuration de règle JUnit

Le serveur Wiremock peut être utilisé avec les tests JUnit en tant que configuration de règle JUnit. Avec cela, JUnit prend en charge le cycle de vie de Wiremock, c'est-à-dire que Wiremock démarre et s'arrête.

comment déclarer un tableau multidimensionnel en java

Il est principalement utilisé dans les configurations où vous souhaitez démarrer et arrêter le serveur après chaque test.

Cela a ses propres avantages d'être isolé et a un haut degré de configurabilité par rapport à une configuration autonome où plusieurs personnes peuvent finir par utiliser le même serveur et passer les réponses les unes sur les autres.

Voyons un exemple concret de cette approche:

#1) Créez une règle JUnit pour le serveur Wiremock. Cette étape ressemble essentiellement à une étape de configuration de test où nous disons au coureur JUnit d'instancier le serveur Wiremock avant chaque test et d'arrêter le serveur après chaque test.

Cela signifie également que JUnit runner se chargera du démarrage et de l'arrêt du serveur Wiremock, sans le faire explicitement.

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

#deux) Nous allons maintenant écrire notre test où nous allons d'abord créer notre client (en utilisant okHttp) pour exécuter les requêtes sur le point de terminaison souhaité.

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

# 3) Mais, vous pouvez remarquer ici que nous n'avons toujours défini aucun stub à renvoyer pour notre instance Wiremock. c'est-à-dire que le client ci-dessus demandera une URL http: // localhost: 8080 / test / abc qui n'a pas de stub configuré. Dans ce cas, le serveur Wiremock retournera un 404 no content.

# 4) Maintenant, afin de définir un stub pour l'URL ci-dessus pour notre instance de serveur Wiremock, nous devrons appeler les méthodes statiques de stub de Wiremock comme indiqué ci-dessous.

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

Ici, vous pouvez voir que nous avons utilisé quelques méthodes statiques telles que configureFor, stubFor, etc. Toutes ces méthodes font partie de la bibliothèque Java Wiremock. (Nous examinerons ces méthodes en détail dans notre prochain tutoriel / sections)

# 5) Maintenant, avec l'étape de configuration terminée, nous pouvons simplement exécuter la demande via le client et valider la réponse (en fonction de ce qui est configuré pour que le stub retourne via Wiremock)

Pour résumer, voici à quoi ressemblerait l'ensemble de l'exemple de code:

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!'))); } }

Dépendances requises

Il est disponible en:

  • Un JAR autonome contenant uniquement la dépendance Wiremock.
  • Un gros pot contenant Wiremock et toutes ses dépendances.

Les deux versions sont disponibles en tant que dépendances Gradle et Maven. Plus de détails sont disponibles sur le référentiel officiel Maven Ici

Tutoriel vidéo: Wiremock avec JUnit Test

Conclusion

Dans ce didacticiel, nous avons parcouru les fonctionnalités de base de Wiremock et vu comment il peut être exécuté en tant que serveur autonome et dans le cadre des tests JUnit à l'aide des règles JUnit.

Nous avons également abordé brièvement le stubbing et nous le couvrirons en détail dans notre prochain tutoriel.

Tutoriel SUIVANT

lecture recommandée

^