Stratégie de tests dans l’application Zéphir

Les différents types de tests

Tests unitaires

Les tests unitaires ont pour objectif de vérifier le bon fonctionnement d’un code donné, de manière la plus “atomique” possible. Par exemple, dans le cadre de l’application Zéphir, un test unitaire pourra exécuter la fonction qui vérifie les données transmises avec un message pour s’assurer de leur validité, et vérifier que celle ci détecte correctement les problèmes de format ou de données manquantes.

Les tests unitaires ne devraient avoir de dépendance envers un environnement particulier. Leur exécution devrait être rapide (ils ne testent “que” du code).

Tests d’intégration

Les tests d’intégration ont pour objectif de vérifier le bon fonctionnement de l’interaction entre différentes “briques” fonctionnelles. Par exemple, dans le cadre de l’application Zéphir un test d’intégration pourra simuler l’envoi d’un message sur le bus de message et vérifier que le(s) microservice(s) associé(s) réagit/réagissent correctement à celui ci.

Les tests d’intégration nécessitent généralement d’avoir une partie de l’environnement technique pour être exécutés, cette partie étant souvent contenue dans le domaine fonctionnel du/des service(s) à tester. Ils nécessitent parfois également de données d’amorçage pour créer un contexte particulier.

Tests de bout en bout

Les tests de bout en bout (ou “end to end”) à pour objectif de vérifier le bon fonctionnement de scénarios “réels” d’utilisation de l’application. Par exemple, dans le cadre de l’application Zéphir, un test de bout en bout pourra simuler une authentification d’un utilisateur, la création d’un nouveau modèle de serveur, l’enregistrement d’un serveur sur ce modèle et l’application d’une configuration sur ce serveur.

Les tests bout en bout nécessitent généralement d’avoir un environnement complet afin de pouvoir fonctionner. Dans le cadre de l’application Zéphir, cela sous entend avoir également des serveurs pouvant être rattachés à l’instance Zéphir.

La pyramide des tests

Principes généraux de la pyramide:

  • Plus on monte dans les étages, plus les tests sont coûteux à implémenter/exécuter/maintenir.
  • Plus on monte dans les étages, plus les tests couvrent un domaine fonctionnel large de l’application.
  • Plus on monte dans les étages, moins on devrait avoir de tests (voir les deux premiers principes).

Pour plus d’informations, voir la présentation de Martin Fowler dans la biblio.

Dans l’application Zéphir

Objectifs de la stratégie de test

  • On devrait pouvoir exécuter les suites de tests des différents services séparément.
  • On devrait pouvoir exécuter les suites de tests d’un type donné (unitaires/intégration/bout à bout) séparément.
  • On devrait pouvoir exécuter les opérations précédentes sur une version de l’application de production.

Ce dernier point soulève la nécessité d’extraire les procédures de test des conteneurs de développement.

Outillage et principes

  • On profite des capacités de docker-compose pour embarquer les tests des différents microservices dans leurs propres conteneurs
  • Un conteneur de test se verra exposé une variable d’environnement ZEPHIR_TEST_TYPE lors de son exécution qui indiquera le type de tests à exécuter
  • Un script (script/test) permet d’exécuter les tests unitaires/d’intégration/bout en bout d’un ou plusieurs microservices et d’agréger les résultats
  • Il sera possible d’exécuter la batterie de tests “bout en bout” en la faisant pointer vers une instance Zéphir iso-prod en configurant docker-compose pour qu’il utilise le bon réseau (voir l’aide du script scrip/test)

Créer un test pour un microservice

Si vous avez utilisé le script script/test pour générer l’arborescence de fichiers pour votre microservice, la procédure ci dessous est déjà réalisée en partie pour vous.

  1. Dans le répertoire services/<votre_service>/ créer un fichier Dockerfile.Test
  2. Dans le fichier docker-compose.test.yml, ajouter les éléments suivants dans la section services:
<votre_service>-test:
  build:
    context: services
    dockerfile: <votre_service>/Dockerfile.Test
  depends_on:
    - <votre_service>
  1. Le point d’entrée de votre conteneur (le script ou la commande définie par la directive CMD du fichier Dockerfile.Test) devrait lancer vos suites de test en fonction de la valeur de la variable d’environnement ZEPHIR_TEST_TYPE qui pourra prendre les valeurs unit, integration ou e2e. Si un test échoue, votre commande devrait terminer avec un code de sortie différent de 0.
  2. Pour lancer les tests de votre service, vous pouvez exécuter la commande suivante script/test unit <votre_service>-test