Votre suite de bout en bout prend quatre heures et les développeurs ont cessé de l'attendre. Comment corrigez-vous cela ?

Attaquez sur quatre fronts : parallélisez sur plusieurs workers, redescendez la couverture dans la pyramide pour que des tests d'API et unitaires remplacent des parcours d'interface lents, supprimez les tests redondants et de faible valeur, et accélérez la préparation en créant l'état via l'API plutôt que par l'interface. Découpez ensuite la suite pour qu'un sous-ensemble rapide conditionne les fusions et que l'exécution complète se fasse la nuit.

D'abord je récupère les données, parce que deviner quels tests sont lents se révèle en général faux. Je sors les durées par test et je trouve presque toujours un petit nombre de tests qui avalent une part disproportionnée, souvent à cause de pauses fixes ou d'une préparation pilotée par l'interface. La parallélisation est le gain structurel le plus rapide, mais elle ne marche que si les tests sont correctement isolés, ce qui veut dire en général corriger d'abord les données de test partagées. Le levier le plus fort, c'est le rééquilibrage. Je regarde chaque test de bout en bout et je demande ce qu'il prouve vraiment. Un test qui traverse six écrans pour vérifier un message de validation est un test unitaire déguisé, et sa place est à une couche où il tourne en millisecondes. Ensuite je supprime, ce que les gens trouvent inconfortable. Les tests qui n'ont jamais échoué pour une vraie raison, ceux qui doublonnent une couverture existant ailleurs, ceux de fonctionnalités que personne n'utilise. Une couverture qui coûte plus qu'elle ne rapporte est un passif. Et je fais la préparation via l'API, donc un test de commande crée son compte et son panier en deux appels au lieu de quinze chargements de page. Enfin je découpe : quinze minutes de chemin critique à chaque fusion, suite complète la nuit.