Tests Zéphir¶
Chaque service peut avoir, en plus de son fichier standard (compose/dev/<service>.yml), un fichier de test(compose/test/<service>.yml). Si ce dernier fichier de test existe, il sera lancé par le pipeline d’intégration continue dans 2 modes distincts :
- Mode isolé
- Mode intégré
La différenciation de ces deux mode se fait par le passage d’une variable d’environnement (TEST_ENV) au conteneur.
Mode intégré¶
TEST_ENV prendra la valeur « integrated » (eg. TEST_ENV=integrated) Dans ce mode, le conteneur de test est lancé avec l’ensemble des autres services, afin des réaliser des tests d’intégration.
Mode isolé¶
TEST_ENV prendra la valeur « isolated » (eg. TEST_ENV=isolated)
Dans ce mode, seul le conteneur de test est lancé, afin de réaliser des tests unitaires.
Voir aussi¶
- Le fichier Jenkinsfile, stage « run isolated tests » et « run integrated tests », lignes 109 et 126 respectivement
- Le script bin/ci, fonctions « run_service_tests » et « run_integrated_tests », lignes 48 et 30 respectivement
Mise en place de tests unitaires (scénario 25049)¶
- 1 conteneur dédié aux tests unitaires par services :
- 1 Dockerfile.Test (installant postgreSQL localement)
- 1 compose/test/*-test.yml avec des variables d’environnement :
- ZEPHIR_TEST_TYPE: unit => obligatoire
- ZEPHIR_TEST_COVERAGE_PATTERN: /usr/lib/python3/dist-packages/identity/* => optionnelle
- 1 script de lancement des tests : services/*/scripts/test (peut éventuellement être centralisé)
- 1 dossier de tests unitaires pytest : services/*/test contenant un fichier util.py (permettant la création de la base, éventuellement centralisable aussi)
Le conteneur de tests exécute les tests unitaires et renvoie un code retour (0 = OK, autre chose = KO) si le coverage est demandé, une sortie l’affiche et un rapport HTML est placé dans le dossier services/*/report