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