Tests d’intégration avec les extensions Arquillian sur la plateforme Payara

Arquillian est l’un des frameworks de test d’intégration les plus classiques pour les applications basées sur JVM (Java Virtual Machine), actuellement maintenu par Red Hat. Sa principale particularité consiste dans le fait que, pour faciliter les tests d’intégration à travers le maven cycle de vie, il permet le déploiement des applications testées sur un conteneur intégré, géré ou distant compatible Jakarta EE, comme Payara.

Du test d’intégration manuel au test d’intégration automatisé

Historiquement parlant, le processus de test d’intégration était une activité hautement manuelle, consistant à déployer l’application sur le serveur d’application avant d’exécuter les cas de test. Cela est notamment dû à l’utilisation d’outils de construction comme maven quel cycle de vie par défaut provisionne la phase de test d’intégration, nommée verifyjuste avant install et deploy. Cela signifie que les tests d’intégration en conteneur ne peuvent pas être effectués de manière standard avec de tels outils, car ils sont exécutés avant la phase de déploiement, même si, pour être exécutés, ils nécessitent que les applications soient déployé. Donc, on se retrouve ici dans une sorte de problème circulaire : pour tester l’application il faut d’abord la déployer, et pour la déployer il faut d’abord la tester. C’est pourquoi les tests d’intégration étaient traditionnellement effectués manuellement.

Les choses ont changé avec l’introduction des tests automatisés basés sur le framework JUnit. Ce cadre définit la notion de Test de l’unité comme un morceau de code destiné à prouver qu’une fonctionnalité spécifique donnée dans l’application fonctionne comme prévu. Et puisque tester de telles fonctionnalités dans un isolement complet ne serait pas possible, en raison de leur dépendance à d’autres composants logiciels ou à des éléments d’infrastructure complexes, une nouvelle technique, appelée railleura émergé.

Cette technique consiste à utiliser objets factices qui agissent comme médiateurs entre le code de test et les composants testés. En fait, au lieu d’appeler des composants réels, les cas de test appellent maintenant les objets fictifs qui affirment simplement que les méthodes correctes sont appelées, avec les signatures correctes, renvoyant les résultats corrects. De cette façon, nous, en tant que développeurs, sommes en mesure de nous débarrasser des dépendances complexes du code testé et de le tester de manière isolée, prouvant ainsi qu’il devrait fonctionner, dans la mesure où il s’exécute dans un contexte entièrement déterministe, où toutes les contraintes requises sont satisfait.

Le problème avec cette approche est qu’elle nous oblige non seulement à refactoriser le code de manière à ce qu’il soit conforme aux interfaces de l’objet fictif, mais en plus, elle ne nous permet pas de tester des objets réels ; plutôt, des simulacres. En effet, prouver que le code fonctionne comme prévu, dès que le contexte d’exécution est parfaitement déterministe et que toutes les contraintes sont satisfaites, n’est pas très utile car on est rarement dans un tel contexte. En dehors de cela, le but ultime de l’activité de test est de prouver qu’en fait, nos composants logiciels sont suffisamment flexibles et fonctionnent comme prévu, quelles que soient les différentes variations, causées par un éventuel contexte instable.

Enfin, il n’existe aucun moyen cohérent de tester automatiquement les composants complexes du logiciel Jakarta EE tels que les servlets, les EJB, JPA et autres, car :

Les tester dans le conteneur nécessite un déploiement, ce qui n’est pas possible car la phase de test automatique des outils s’exécute avant le déploiement.
Les tester isolément nous oblige à simuler de nombreuses dépendances et, ce faisant, nous ne testons pas nos composants réels ; juste des objets simulés.

Introduction à Arquillian

Contrairement à d’autres frameworks de test, Arquillian effectue toute la plomberie requise pour la gestion et le déploiement des conteneurs, en fournissant les éléments suivants :

Une plate-forme d’exécution de test, telle que JUnit 4, JUnit 5, Jupiter ou TestNG
Un ensemble de conteneurs tels que Payara, Wildfly, Glassfish, Tomcat, WebLogic, WebSphere, etc.
Un ensemble d’enrichisseurs de test visant à tirer parti de l’intégration des cas de test dans les conteneurs ci-dessus
La bibliothèque ShrinkWrap facilite la définition et le chargement des descripteurs de déploiement. Notez que ShrinkWrap est une bibliothèque externe et, en tant que telle, elle n’appartient pas à Arquillian, même si elle est généralement utilisée dans les tests d’intégration basés sur Arquillian.

Un cas de test arquillien est divisé en deux domaines principaux :

La déploiement section, qui conditionne et déploie l’application testée sur le serveur d’application
La test section, qui effectue les opérations de test réelles basées sur la plate-forme d’exécution sélectionnée (JUnit ou TestNG).

Quant aux conteneurs de serveur d’applications pris en charge, ils se présentent sous les formes suivantes :

Conteneurs intégrés s’exécutant dans la même JVM que les scénarios de test
Conteneurs gérés s’exécutant dans une autre JVM ; alors les cas de test peuvent être démarrés et arrêtés par eux
Des conteneurs distants qui s’exécutent de manière totalement indépendante

Cube Arquillien

Nous avons décrit ci-dessus un scénario typique d’utilisation du framework Arquillian Core dans les tests d’intégration. L’avènement des technologies basées sur les conteneurs Linux, comme Docker et OCI (Open Container Initiative), a démontré que ces plates-formes constituent des environnements de test parfaits, grâce à leurs attributs fiables et reproductibles. Mais l’utilisation de conteneurs Linux avec des tests d’intégration Arquillian (c’est-à-dire les conteneurs Docker) oblige les développeurs à gérer les machines hôtes et les adresses IP, ainsi qu’à adapter les scripts de construction de manière à fournir des étapes spécialisées qui créent des images ou des conteneurs et les lancent (c’est-à-dire , en exécutant manuellement docker ou docker-compose commandes). Et même si l’exécution manuelle de telles commandes peut être une bonne approche, nous devons nous rappeler que les tests d’intégration doivent être auto-exécutables autant que possible et ne nécessitent pas d’intervention manuelle ou de temps d’exécution compliqués.

Entrez Arquillian Cube : Il s’agit d’une extension Arquillian qui aide à gérer les conteneurs et les images Docker dans les tests d’intégration basés sur Arquillian. Il utilise une approche similaire à celle d’Arquillian Core pour les serveurs d’applications mais adaptée pour les conteneurs Docker. Il peut être utilisé dans les cas suivants :

Préparation des environnements de test
Test des opérations de construction Dockerfile
Validation des compositions Docker Compose
Réalisation de tests boîte blanche et boîte noire

Le lecteur averti a certainement remarqué quelques similitudes avec un autre outil de test largement utilisé actuellement avec les conteneurs Docker : testcontainers. Ces lecteurs seraient probablement ravis de savoir qu’Arquillian Cube pourrait être considéré comme une sorte de combinaison d’Arquillian Core et testcontainers. La figure ci-dessous montre le cycle de vie du cube Arquillian.

Comme le montre la figure ci-dessus, avant d’exécuter les tests d’intégration, Arquillian Cube lit un fichier Docker Compose et démarre tous les conteneurs Docker dans le bon ordre. L’extension attend alors que tous les services soient opérationnels pour pouvoir recevoir des connexions entrantes. Ensuite, les tests sont exécutés et, une fois terminés, tous les conteneurs Docker en cours d’exécution sont arrêtés et supprimés.

La preuve de concept

Afin de démontrer comment le processus de test d’intégration pourrait être mené avec les serveurs d’applications Payara, nous fournissons une preuve de concept (POC). La plate-forme de coureur que nous utilisons dans ce POC est JUnit 4 et 5 (l’utilisation d’une plate-forme de coureur TestNG est très similaire). Ainsi, notre projet s’articule autour de deux maven modules nommés with-junit-4 et, respectivement, with-junit-5.

Pour faire l’expérience de ce POC, vous avez bien sûr besoin d’un démon Docker en cours d’exécution sur votre machine. Sous le capot, ce démon utilise des sockets Linux pour communiquer avec les clients. C’est parfait pour les utilisateurs de Linux. Cependant, si vous utilisez Windows ou Mac, alors boot2docker ou docker-machine pourrait également être nécessaire.

Arquillian Cube prend en charge trois types de tests d’intégration :

La déployable tests d’intégration sont ceux avec lesquels les utilisateurs Arquillian Core sont déjà utilisés. Ils nécessitent la section de déploiement que nous avons mentionnée précédemment où, grâce à la bibliothèque ShrinkWrap, un WAR ou JAR minimal, contenant les composants à tester, est créé et déployé sur le serveur d’application cible. La seule différence ici est que le serveur d’application cible s’exécute, dans le cas d’Arquillian Cube, dans un conteneur Docker séparé.
La objet conteneur-basé tests d’intégration: L’objet conteneur est un pattern inventé par la communauté Arquillian qui consiste à encapsuler, de manière orientée objet, les données et actions liées aux conteneurs, de manière à ce qu’elles puissent être réutilisées dans différents tests d’intégration.
La DSL (langage spécifique au domaine)-basé tests d’intégration : Arquillian Cube fournit un DSL qui peut être utilisé pour créer et instancier dynamiquement des conteneurs.

Notre POC inclut un sous-projet Maven illustrant chacune des versions ci-dessus disponibles avec les deux plates-formes d’exécution prises en charge : JUnit 4 et 5. Examinons ces tests d’intégration.

Les tests d’intégration déployables

Afin d’implémenter nos tests d’intégration, nous considérons un cas d’utilisation très simple, celui d’un « Hello, world! » servlet dont le code est présenté ci-dessous :

@WebServlet("/hello")
public class HelloServlet extends HttpServlet
{
  @Override
  protected void doGet(HttpServletRequest req, HttpServletResponse resp)
    throws ServletException, IOException
  {
    PrintWriter writer = resp.getWriter();
    writer.println("Hello World");
  }
}

Ce même code sera réutilisé dans tous les projets POC. Afin de le tester, nous implémentons le test d’intégration suivant :

@RunWith(ArquillianConditionalRunner.class)
public class PayaraServerFullIT
{
  @ArquillianResource
  private URL url;

  @Deployment(testable = false)
  public static WebArchive onPayara()
  {
    return ShrinkWrap.create(WebArchive.class, "hello.war").addClass(
      HelloServlet.class);
  }

  @Test
  public void testOnPayaraShouldReturnOk() throws MalformedURLException
  {
    given()
      .contentType(ContentType.JSON)
      .get(new URL(url + "/hello"))
      .then()
      .assertThat().statusCode(200)
      .and()
      .body(containsString("Hello World"));
  }
}

Il s’agit d’un test d’intégration déployable…