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