Réponse.

Historiquement, avec l'augmentation du nombre de tests automatisés dans les projets, des problèmes se sont manifestés : les tests se mélangeaient, dépassaient les limites de temps d'exécution, il était difficile de comprendre ce qui était responsable de quoi. De plus, le risque d'émergence de dépendances entre différentes parties du système de test augmentait, ralentissant le travail global des pipelines.

Le problème se pose lorsque le nombre de tests augmente plus rapidement que le support architectural de l'infrastructure de test. Sans solutions scalables, les tests deviennent lents, difficiles à maintenir, la recherche et la localisation des défauts se compliquent et la dette technique augmente rapidement.

La solution réside dans l'implémentation de stratégies spécifiques :

La clustering des tests par modules et niveaux (unité, intégration, E2E) en utilisant des tags et des filtres appropriés.
L'exécution parallèle des tests (sharding, suites de tests distribuées) pour accélérer l'exécution.
L'utilisation d'une approche microservices dans l'infrastructure de test : abstractions DSL standard, services séparés pour la gestion de l'infrastructure de test.
L'automatisation de la détection des tests redondants et obsolètes, le refactoring régulier et l'audit de la couverture.

Caractéristiques clés :

La modularité et la réutilisabilité des tests et des bibliothèques de tests.
L'automatisation complète des intégrations CI/CD et la possibilité d'autoscaling des ressources.
L'introduction d'outils de surveillance de la qualité des tests automatisés et de la couverture du code.

Questions piégeuses.

Est-il possible de ne faire que des tests d'intégration pour couvrir plus de code en même temps ?

Non, cette approche diminue la localisation des défauts et conduit à un coût de maintenance élevé, ainsi qu'à un ralentissement de l'exécution des régressions.

La scalabilité des tests automatisés signifie-t-elle uniquement leur accélération ?

La scalabilité implique l'architecture, la maintenabilité, l'accélération et une infrastructure flexible. L'accélération n'est qu'une conséquence d'un système bien conçu.

Comment bien scaler les tests pour des équipes travaillant dans différents fuseaux horaires ?

Il est important de prévoir la possibilité d'exécutions locales et l'indépendance des environnements de test, sinon il y aura des « conflits » entre les tâches des équipes.

Erreurs typiques et anti-patterne

Tous les tests sont écrits dans un seul dossier sans structuration par domaines.
Réutilisation directe des données de test (« copy-paste » au lieu de bibliothèques/fixtures).
Absence de surveillance/métriques concernant le temps d'exécution et la stabilité des tests.

Exemple de la vie réelle

Cas négatif

Dans une entreprise, plusieurs équipes ont immédiatement commencé à ajouter de nouveaux tests automatisés dans un même dossier sans coordonner leurs changements. Après quelques semaines, les tests automatisés ont échoué en raison d'incohérences dans les données et les dépendances, et le temps d'exécution a dépassé 2 heures.

Avantages :

Faible barrière d'entrée pour les débutants.
Démarrage rapide de l'automatisation.

Inconvénients :

Absence de scalabilité.
Difficulté à trouver et analyser les erreurs.
Ralentissement de la sortie des produits.

Cas positif

Dans l'une des équipes, une structure modulaire a été mise en place, un CI séparé par domaine de code a été introduit, la stabilité a été améliorée et des alertes automatiques sur les tests inefficaces ont été mises en œuvre.