Concevoir pour la testabilité : Lever la prochaine barrière

Dans notre série DevOps for the Win, nous avons documenté notre parcours de transformation DevOps. Au chapitre 1, nous avons présenté le Triangle DevOps : Outils, architecture et personnel dans le développement de produitsdans lequel nous avons discuté des éléments fondamentaux qui conduisent au succès de DevOps. Dans le chapitre 2, nous avons exploré Les premières étapes de notre transformation DevOpsoù nous expliquons comment nous avons jeté les bases de changements significatifs.

Dans le chapitre 3, nous abordons le prochain défi majeur auquel nous avons été confrontés : concevoir pour la testabilité. Après avoir amélioré la structure de notre équipe, affiné notre définition du « terminé » et mis en place une analyse automatisée du code, nous avons réalisé que le principal goulot d'étranglement dans notre pipeline était désormais la conception logicielle, et plus précisément la testabilité. Le travail s'accumulait dans la phase de test, us les cycles de publication. Ce chapitre explore comment nous avons surmonté ce défi et amélioré notre capacité à fournir efficacement des logiciels de haute qualité.

Le goulot d'étranglement des tests

La raison principale de ce retard était que les tests étaient essentiellement manuels, se concentrant sur les tests de l'interface utilisateur et les flux de travail des utilisateurs. L'interface utilisateur étant généralement l'un des derniers éléments à être achevé, il n'y avait que peu ou pas d'automatisation en place, et les tests manuels devenaient la seule approche viable. Les cas de tests automatisés de l'interface utilisateur (par exemple, les tests Selenium) étaient généralement rédigés une fois les tests manuels terminés, principalement à des fins de régression.

Cette dépendance à l'égard des tests manuels s'est traduite par une baisse de la productivité.

• Des retards importants dans la mise à disposition des logiciels.
• La nécessité de déploiements multiples pour permettre des tests parallèles par plusieurs membres QA .

Cela a mis en évidence l'importance de rendre le code plus testable afin d'optimiser le flux de valeur. Cependant, cet objectif s'est avéré plus difficile à atteindre que nous ne l'avions prévu.

Priorité aux tests d'API et aux tests unitaires

Pour relever ce défi, nous nous sommes concentrés sur deux domaines principaux :

1. Tests unitaires - S'assurer que les composants individuels peuvent être testés de manière isolée.
2. Tests de l'API - Réduction de la dépendance à l'égard des tests basés sur l'interface utilisateur et des dépendances à l'égard de la base de données.

Test de l'API : Passer à gauche pour un retour d'information plus rapide

Nous avons redéfini notre stratégie de test des API grâce à ces améliorations clés :

1. APIs bien définies APIs APIs conçues pour être simples, bien documentées et disponibles dès le début du développement.
2. Éviter les bases de données comme point d'intégration - Le fait de s'appuyer sur des bases de données pour l'intégration a créé des dépendances qui ont ralenti les tests. Nous avons plutôt opté pour une intégration basée sur des API utilisant REST sur HTTP et GraphQL. Cela a permis de minimiser le temps de configuration de la base de données et d'améliorer l'automatisation des tests.

Cette évolution a permis de réduire considérablement les délais, en accélérant l'automatisation et les tests préliminaires, ce qui montre que le fait de privilégier les conceptions fondées sur l'API améliore à la fois la testabilité et l'efficacité.

Tests unitaires : Un changement d'état d'esprit

Au départ, nos efforts en matière de tests unitaires ont permis d'augmenter rapidement la couverture des tests, mais nous avons rapidement identifié des problèmes :

• Certains tests étaient superficiels, rédigés uniquement pour atteindre les objectifs de couverture du code.
• Ils manquaient de validation significative des fonctionnalités, des cas limites et des scénarios d'échec.

Pour contrer ce phénomène, nous avons mis l'accent sur la nécessité d'une action de sensibilisation et de formation :

• Former les développeurs à l'écriture de tests valables.
• Refonte du code pour améliorer la testabilité.

Les défis de l'écriture d'un code testable

Le principal obstacle à l'efficacité des tests unitaires était le manque de testabilité de la base de code elle-même. Les principaux problèmes étaient les suivants

• Grandes fonctions monolithiques.
• Composants étroitement liés.
• Mauvaise séparation des préoccupations.
• Abstraction insuffisante.

Il était donc difficile d'isoler et de tester efficacement les unités individuelles. Pour y remédier, nous avons

1. Lignes directrices fournies: Nous avons partagé les meilleures pratiques sur :
   • Sélection des fonctions pour les tests unitaires.
   • Refonte du code pour améliorer la testabilité.
   • Concevoir et utiliser des mocks pour faciliter les tests.
2. L'accent a été mis sur les améliorations progressives: Les développeurs ont été encouragés à apporter de petites modifications significatives pour améliorer la testabilité au fil du temps.

Des progrès lents mais constants

Malgré ces efforts, les progrès ont été lents, en particulier pour les produits existants. L'architecture existante limitait le nombre de tests unitaires que nous pouvions écrire. Cependant, ces actions ne visaient pas seulement à améliorer le code actuel, elles constituaient un investissement pour l'avenir:

• L'amélioration des compétences des développeurs en matière de conception de codes testables a permis d'éviter que les projets futurs ne connaissent les mêmes problèmes.
• Des améliorations progressives ont permis d'éviter les perturbations tout en augmentant régulièrement la couverture de l'automatisation des tests.
• Un changement d'état d'esprit a permis aux équipes de considérer la testabilité non pas comme un fardeau mais comme une nécessité pour un succès durable de DevOps.

Pour les équipes et les organisations qui se lancent dans une transformation DevOps, la testabilité est un domaine critique. Elle permet d'atténuer les goulets d'étranglement dans la phase de développement. Cependant, il est important de gérer les attentes - des résultats immédiats peuvent ne pas être possibles, en particulier lorsqu'il s'agit d'importantes bases de code héritées. Le remaniement d'un tel code sans tests unitaires et de régression suffisants constitue un défi majeur.

Les leçons du programmeur pragmatique

Dans les cas où il n'est pas possible de commencer par une nouvelle base de code, The Pragmatic Programmer : Your Journey to Mastery, d'Andy Hunt et David Thomas, offre des conseils pratiques :

• Cibler les changements incrémentaux: Se concentrer sur le remaniement de petites parties gérables de la base de code.
• Découpler les composants: Réduire les dépendances pour rendre les unités individuelles plus faciles à tester.
• Décomposer les fonctions monolithiques: Diviser les grandes fonctions en unités plus petites et plus ciblées.
• Adopter une conception modulaire: Rendre le code plus testable et plus facile à maintenir en améliorant la modularité.

Le message est clair : une fois que les goulets d'étranglement initiaux ont été éliminés, la testabilité doit devenir un domaine d'intérêt majeur. Cela permettra d'alléger les contraintes de la phase de test et de livrer plus rapidement des logiciels de haute qualité.

Perspectives d'avenir

Notre parcours vers l'amélioration de la testabilité us a enseigné des leçons us sur le rôle de la conception logicielle dans la facilitation des transformations DevOps. En mettant l'accent sur la testabilité, nous avons résolu les goulots d'étranglement, amélioré les compétences des développeurs et posé les bases de notre réussite future. Même si les résultats immédiats peuvent être lents à se manifester, les avantages à long terme en termes de qualité, d'efficacité et de croissance de l'équipe justifient pleinement cet investissement.

À mesure que nous poursuivons notre voyage DevOps, la mesure du succès devient le prochain défi majeur. Au chapitre 4, nous verrons comment nous avons mis en place des indicateurs de performance clés et des tableaux de bord pour suivre nos progrès et identifier d'autres domaines d'amélioration.

Restez à l'écoute, car nous allons vous expliquer comment la prise de décision basée sur les données us a aidés us nos processus DevOps et à optimiser nos performances !