Automatisation des Tests: Clé de l'Intégration Continue
Tests automatisés et CI : comment je structure mes projets
La qualité d'un pipeline CI se mesure à la qualité de ses tests. Pas à leur nombre, mais à leur pertinence et leur fiabilité. Après 15 ans de mise en place de CI sur des projets variés, voici ma méthodologie pour construire une suite de tests qui apporte réellement de la valeur.
Choisir les bons tests au bon moment
La première erreur que je vois chez mes clients : vouloir tout tester dès le départ. Chez Coopengo, en arrivant, j'ai trouvé une suite de 800 tests unitaires dont 200 étaient en échec permanent et ignorés. C'est pire que pas de tests du tout, parce que personne ne fait confiance au pipeline.
Mon approche : commencer par identifier les 10 parcours utilisateurs les plus critiques et écrire des tests d'intégration pour ceux-là. Chez Coopengo, ces 10 tests couvraient 80% de la valeur métier (inscription, authentification, commande, paiement, facturation). Ils prenaient 3 minutes à exécuter et attrapaient la majorité des régressions.
Les tests d'infrastructure : le parent pauvre
On parle beaucoup de tests applicatifs, mais rarement de tests d'infrastructure. Pourtant, une erreur dans un module Terraform peut être aussi destructrice qu'un bug dans le code applicatif.
Chez F2R2, chaque module Terraform (25 au total) avait son propre terraform validate et terraform plan exécutés dans la CI. Plus intéressant : nous utilisions terratest en Go pour certains modules critiques (networking, IAM) qui déployaient réellement l'infrastructure dans un compte de test, vérifiaient le résultat, puis la détruisaient. Le feedback loop était plus long (5-10 minutes par module), mais la confiance dans les modifications était totale.
Chez Epiconcept, les rôles Ansible étaient testés avec Molecule. Chaque rôle avait un scénario de test qui lançait un container Docker, appliquait le rôle et vérifiait les assertions (service démarré, port en écoute, configuration correcte). Un changement dans le rôle MariaDB était validé automatiquement avant le merge.
Tests de sécurité dans la CI
Depuis mes missions dans des environnements réglementés (KNDS Défense, Okeiro HDS, Bloomflow ISO 27001), j'intègre systématiquement des tests de sécurité dans chaque pipeline CI.
Le scan d'images Docker avec Trivy est le plus simple à mettre en place : une commande qui analyse l'image et remonte les CVE. Chez KNDS, seules les CVE critiques bloquaient le merge. Les CVE hautes étaient remontées en warning avec un délai de correction de 7 jours.
Le scan de dépendances applicatives (npm audit, pip-audit, bundler-audit) détecte les bibliothèques vulnérables. L'analyse statique du code Terraform avec tfsec identifie les mauvaises pratiques (bucket S3 public, security group trop permissif, encryption manquante).
Le piège des tests flaky
Les tests intermittents (flaky tests) sont le cancer de la CI. Un test qui échoue une fois sur dix détruit la confiance dans le pipeline et pousse les développeurs à ignorer les échecs.
Chez Bloomflow, nous avions un test e2e qui échouait quand la base de données de test mettait plus de 2 secondes à répondre. La solution n'était pas d'augmenter le timeout, mais de mocker la dépendance externe. Les tests doivent être déterministes : même input, même output, à chaque exécution.
Ma règle : si un test échoue de manière intermittente, il est immédiatement marqué comme à corriger ou supprimé. Un pipeline avec 100 tests fiables vaut infiniment mieux qu'un pipeline avec 150 tests dont 10 sont flaky.
Mesurer la couverture : utile mais pas suffisant
La couverture de code est un indicateur utile mais trompeur si pris isolément. Sur WizOps.fr, mon propre projet, j'ai 51 tests répartis sur 15 fichiers. La couverture n'est pas de 100%, mais chaque test couvre un comportement critique. Un test qui vérifie que le formulaire de contact envoie bien les données à l'API a plus de valeur que 20 tests unitaires de fonctions utilitaires.
Mon conseil : visez une couverture raisonnable (70-80%) sur le code métier critique, et ne perdez pas de temps à atteindre 100% sur du code de configuration ou de boilerplate.