Architecture de test automatisé : un guide rapide pour les équipes qui ont besoin de rapidité

La plupart des équipes n'ont pas de problème de « manque de tests ». Il y a un problème avec les tests mal architecturés.

Ils commencent avec de bonnes intentions. Quelqu'un rédige un test, puis un autre, et en quelques mois, on obtient une suite contenant des centaines de cas. Le problème apparaît lorsque cette suite commence à prendre vingt minutes à s'exécuter, s'interrompt à cause d'un changement insignifiant et que personne ne fait plus confiance au résultat rouge. La réaction naturelle est de désactiver le test « toujours en échec ». Dès lors, la suite devient un théâtre.

Ce guide est simple : avant de discuter de l'outil à utiliser, décidez de l'architecture de vos tests. C'est cette décision qui sépare une suite qui protège l'équipe de celle qui la ralentit.

Pourquoi l'architecture passe avant la couverture

La couverture est une mesure facile à mesurer et facile à tromper. Vous pouvez obtenir une couverture de 90 % en testant les getters et les setters, sans protéger les règles métier importantes.

Ce qui soutient vraiment la vitesse, c'est la façon dont les tests sont organisés : ce que chaque niveau teste, à quelle vitesse ils s'exécutent, à quel point ils sont isolés et avec quelle clarté ils signalent ce qui s'est cassé. Il s’agit d’une décision architecturale et non quantitative.

Je considère cela comme une infrastructure. Vous ne faites pas évoluer un système en empilant des serveurs de manière aléatoire ; définit les niveaux, les responsabilités et les contrats. C'est la même chose avec les tests. Sans conception, la suite se développe comme une dette et non comme un atout.

La pyramide reste le point de départ

La pyramide des tests reste le modèle mental le plus utile pour commencer. La base est constituée de tests unitaires : nombreux, rapides, isolés. Au milieu, des tests d'intégration, qui vérifient si les pièces communiquent entre elles. Au sommet, quelques tests de bout en bout, qui exercent le flux utilisateur.

La règle générale est simple. Plus haut dans la pyramide, plus le test est coûteux, lent et fragile. C'est pourquoi le sommet doit être étroit. Une équipe qui inverse la pyramide, avec des dizaines de tests d’interface et quelques tests unitaires, aura une suite lente et instable.

L’erreur la plus courante ici est de traiter la pyramide comme un dogme. Dans les systèmes très orientés intégration, les API qui orchestrent les services par exemple, il est logique d’épaissir la couche d’intégration. Le format compte moins que le principe : pousser la vérification au niveau le moins cher qui donne encore confiance.

Décisions qui définissent l'architecture

Certains choix ont un impact disproportionné sur la santé de la suite. Cela vaut la peine de les résoudre tôt.

La première est de savoir quoi isoler. Les tests unitaires doivent s'exécuter sans banc, sans réseau, sans véritable horloge. Lorsque vous devez remonter la moitié d'un système pour tester une fonction, le problème n'est pas le test, c'est le couplage de code. Le test n'est qu'un rapport.

La seconde est de savoir comment gérer les dépendances externes. Les simulations et les stubs accélèrent le processus, mais ils mentent : ils testent ce que vous pensez que la dépendance fait, pas ce qu'elle fait. Je réserve donc de vrais tests d'intégration aux limites critiques, au paiement, à l'authentification, à la persistance, et j'utilise les doubles avec parcimonie pour le reste.

Le troisième est l'endroit où se déroulent les tests. Gardez-les à proximité du code qu'ils vérifient. Les suites situées dans des référentiels séparés pourrissent presque toujours, car elles évoluent à un rythme différent de celui du code de production.

La vitesse est une fonctionnalité de la suite

Une suite lente est une suite qui sera ignorée. Si tout exécuter prend une demi-heure, le développeur n’en exécutera qu’une partie, voire rien du tout, et ne découvrira le problème que sur le tapis roulant CI, trop tard.

L'objectif pratique est que la couche Unity s'exécute en quelques secondes, localement, pendant le développement. Cela demande de la discipline : tests parallélisables, pas de dépendance à l'état partagé, pas de sleep pour « attendre » quelque chose. Les attentes fixes sont la plus grande source de lenteur et d'instabilité dans les suites réelles.

En CI, séparez par étape. Exécutez d'abord l'unité, échouez rapidement, puis passez à l'intégration et de bout en bout. Cela ne sert à rien de consacrer dix minutes à un test d’interface si une règle de base est déjà enfreinte.

Le véritable ennemi : les tests intermittents

S’il y a un seul élément qui détruit la confiance dans une suite, c’est bien le test qui réussit parfois et échoue parfois sans que rien ne change. C'est pire que de ne pas avoir de test, car cela apprend à l'équipe à ignorer le rouge.

Les tests intermittents proviennent presque toujours de trois sources : la dépendance temporelle, la dépendance de l'ordre d'exécution et l'état partagé entre les cas. Résoudre ce problème est un travail d’architecture et non de patience. Chaque test doit mettre en place et nettoyer son propre scénario, sans rien supposer de ce qui s'est déroulé auparavant.

Je traite les tests intermittents comme un incident et non comme du bruit. Lorsqu’un apparaît, je le répare ou je le supprime. Garder un test peu fiable dans la suite contamine tous les autres.

Qui garantit la qualité de la suite

Voici la vision du management que de nombreuses équipes ignorent. Le code de test est du code. Il nécessite une révision, une refactorisation et une appropriation. Une suite abandonnée se dégrade au même rythme que tout autre système non entretenu.

Dans les équipes que je dirige, la règle est que tester fait partie de la définition du fait, ce n'est pas une tâche à part poussée jusqu'à la fin du sprint. Et la santé de la suite (temps d'exécution, taux de défaillance intermittente) est incluse en tant que mesure d'ingénierie, aux côtés d'autres que nous surveillons.

Dans le contexte public et dans les produits traitant de données sensibles, cela prend un autre poids. Une suite fiable fait partie de ce qui vous permet de modifier un système critique sans prier pour que quoi que ce soit se brise. Il s’agit de gouvernance, pas de fantaisie technique.

Commencez petit, mais commencez par dessiner

Si votre suite est encore petite, c’est le moment idéal pour mettre en place une bonne architecture. Définissez les niveaux, établissez que les tests unitaires ne touchent pas l'infrastructure, exigez que chaque test soit isolé et traitez la vitesse comme une exigence.

Si la suite est déjà grande et douloureuse, n’essayez pas de tout réécrire. Arrêtez d'abord les saignements : éliminez les saignements intermittents, séparez les étapes du CI et protégez avec de nouveaux tests uniquement ceux qui changent fréquemment. Le reste, on s’améliore petit à petit.

Il n’existe pas de tests automatisés pour prouver que le code fonctionne aujourd’hui. Ils existent pour vous donner le courage de le changer demain. Une bonne architecture de test est, par essence, une assurance contre la peur de faire évoluer le système.

Si votre équipe dispose déjà de tests mais a perdu confiance en eux, cela vaut la peine de revoir l'architecture avant d'écrire un autre cas. J'ai d'autres textes sur le blog sur la qualité et le génie logiciel, et s'il s'agit d'un réel problème dans votre organisation, c'est le type de conversation qui porte ses fruits.