Tests unitaires d’un Client avec Spring Boot

Le code du client EmployeeClient.java est le suivant:

Ce client utilise Feign pour effectuer une requête http simple vers le service distant dont l’url est: http://dummy.restapiexample.com/api/v1/employees.
Feign est une library Java qui permet d’écrire des requêtes HTTP(s) vers des serveurs distants de façon très simple en utilisant des interfaces et des annotations.

L’extrait du code pour tester ce client est le suivant:

Les points importants de ce extrait:

• Nous démarrons un serveur mock HTTP sur le port 12345 grâce à la library open-source Wiremock de Tom Akehurst. Souvenez-vous, nous écrivons un test unitaire, nous ne sommes donc pas censer appeler le vrai service distant. Un test unitaire ne doit pas être soumis aux problèmes de latence ou d’indisponibilité d’un réseau ou d’un fichier. Wiremock permet de fournir des stubs pour faire des appels HTTP(s). Il est configuré avec une @ClassRule Junit, ce qui veut dire que le fake-http-server sera démarré avant l’exécution de toutes les méthodes de tests puis éteind après.
  Nous aurons également puis utiliser l’annotation @Rule, mais dans ce cas le serveur serait démarrer et éteind après l’excécution de chaque méthode de test.
• Comme précédement, chaque méthode de test suit le pattern given-when-then: D’abord nous mettons en place le stub wiremock pour mocker la requête HTTP à effectuer, ensuite nous effectuons cette requête, enfin nous vérifions les retours de notre serveur wiremock.
• Notons également la présence de l’annotation @TestPropertySource qui permet de mocker notre fichier application.properties en y injectant la variable dont a besoin le client Feign.
• Enfin l’annotation @ContextConfiguration nous permet d’injecter dans le contexte Spring la classe de configuration de notre client Feign.

Une des carractéristiques fondamentales d’un test unitaire est sa vitesse d’excécution qui doit s’exprimer en millisecondes.
L’image ci-dessous indique la vitesse d’excécution de l’ensemble des Tests unitaires de notre application témoin:

Remarquez que dans cette partie nous n’avons pas tester unitairement notre repository EmployeeRepository.java. En effet il n’y a aucun code métier ou code custom dans notre repository: Tester unitairement ce repository reviendrait donc à tester le framework spring-data en lui même.

Nous verrons dans la suite de cet article comment tester la couche repository ainsi que l’accès à la base de données grâce aux tests d’intégrations.