Comment une architecture influence votre stratégie de test ? Compte-rendu du talk de Christophe Breheret-Girardin à la Duck Conf 2024
Le verdict de Christophe est sans appel : votre architecture doit conditionner votre stratégie de test. Mais alors, comment choisir la bonne architecture ?
“L’architecture est vraiment importante. Les choses qui sont difficiles à changer sont l’architecture initiale, la culture et les compétences de l’équipe. C’est pourquoi il est important de bien faire les choses dès le départ.”
Martin Fowler, Ingénieur logiciel et auteur.
La bonne architecture repose donc sur :
- Une architecture bien pensée : adapter l’architecture à ses besoins sans pour autant tout anticiper en amont au risque de générer une architecture rigide qui pourrait s’avérer bloquante
- La culture : permettre aux collaborateurs d’être dans une zone de découverte à travers une architecture suffisamment souple pour pouvoir revenir en arrière en cas d’erreur
- Les compétences
Et comment choisir la bonne stratégie de test ? Reprenons tout d’abord l’objectif principal des tests : la qualité.
“Tester c’est diriger les bugs vers la sortie”
Naim BenCharif, QA Analyst.
Des tests de qualité pourront vous servir de spécifications pour réaliser un logiciel ou pour le documenter. La stratégie de test à adopter répond aux mêmes contraintes que vos choix de patterns d’architecture : ça dépend du besoin.
NDLR : pour s’assurer que la qualité de nos applications est au rendez-vous, il me paraît indispensable de déterminer quelques métriques. Par exemple : Quel est le ratio de bugs par fonctionnalité? Combien d’allers-retours QA (Quality Assurance) / développeur.euse par fonctionnalité ?
Évacuer les idées reçues
Il existe différents types de tests, répartis en deux catégories principales : les tests métier et les tests techniques. Dans la première catégorie nous retrouvons les tests produits qui peuvent être automatisés ou manuels ainsi que les tests d’acceptation généralement réalisés par la QA pour s’assurer que le logiciel est utilisable.
Dans la seconde catégorie, nous avons les tests composants, automatisés et à la main des développeurs (tests unitaires, d’intégration et end-to-end) qui permettent de s’assurer de la qualité du code et du bon fonctionnement de l’application ainsi que les tests système automatisés et outillés qui permettent de tester la robustesse du code et de l’infrastructure sur laquelle il repose.
La conférence porte principalement sur les tests automatisés et plus particulièrement sur les tests composants.
1ère idée reçue : “Un test unitaire teste la plus petite portion de code possible”
S’adonner à cette pratique vous expose à un risque presque inévitable de casser le code à chaque changement. In fine les équipes de développement se retrouvent contraintes à commenter ou supprimer ces tests pour pouvoir implémenter les nouvelles fonctionnalités.
2ème idée reçue : “La couverture de tests est le seul et unique indicateur de qualité de code”
Nombre d’entre nous ont en tête le pourcentage magique de couverture de tests (80%), qui peut contraindre les développeurs à penser quantité plutôt que qualité au risque d’induire plus de bugs; c’est l’effet Cobra.
NDLR : La couverture de tests automatisés n’a de sens que si les tests réalisés reposent sur des scénarios réalistes et permettent de limiter le nombre de bugs en environnements de tests ou de production, ou encore de limiter le nombre de tests manuels. Pour ce faire, le pair-testing me paraît adéquat 🙂
3ème idée reçue : “Les QA interviennent en bout de chaîne”
Si vous aussi vous souhaitez garantir la qualité de vos applications, veillez à intégrer la QA dans les équipes de développement, cela ne pourra qu’aider les développeurs à réaliser des tests automatisés de qualité, au plus proche des besoins des utilisateurs.
4ème idée reçue : “Il faut faire des microservices”
Tout ne se vaut pas dans votre application, il y a des contextes et des périmètres différents. Faut-il appliquer la même architecture (ex: les microservices) et la même stratégie de test dans votre système ? La réponse est non. De la même manière, la stratégie de test magique qui s’adapte à toutes les architectures n’existe pas et dépend du contexte.
A chaque besoin son architecture et sa stratégie de test associée
1 - Le besoin métier
Si votre application repose sur des règles métier ou sur un modèle métier complexes, l’architecture hexagonale est faite pour vous. Inventée par Alistair Cockburn, l’architecture hexagonale permet d’isoler les règles métier de tout autre composant. Elle est également connue sous le nom d’architecture “port et adaptateur” permettant à tout adaptateur de venir se plugger sans avoir d’impact sur le cœur de l’application qui renferme les règles métier : le port. Le premier adaptateur à créer est un test. Un autre pattern architectural préconisé est celui de la clean architecture.
La stratégie de test associée à ces types d’architectures est la pyramide de tests : l’effort se concentre principalement sur les tests unitaires, afin de couvrir tous les cas d’usage métier possibles.
A contrario, certains périmètres applicatifs sont utiles mais pas critiques et ne représentent pas le cœur du système. C’est le cas par exemple des référentiels, d’un écran d’administration ou d’un formulaire en mode brouillon.
L’architecture recommandée pour ce cas d’usage est le transaction script : chaque fonctionnalité représente une transaction qui regroupe un ensemble d’étapes.
La stratégie de test associée à une architecture qui suit le pattern transaction script est la pyramide inversée : l’effort se concentre principalement sur les tests end-to-end.
Enfin, si l’intelligence métier de votre application est portée par la donnée avec une nécessité de réaliser une transformation complexe de la donnée, des calculs complexes ou une interaction forte avec une ou plusieurs sources de données (comme par exemple dans le cas de l’utilisation de dashboards), l’architecture recommandée à votre besoin est l’active record. L’intelligence est en base de données et le plus difficile sera d’accéder à la donnée. Les autres couches (services, contrôleurs…) ne servent alors que de passes-plat.
La stratégie de test recommandée est la stratégie en diamant : à partir de la couche d’accès aux données (data access), on réalise tous les tests nécessaires pour vérifier que la donnée a bien été récupérée. En complément, il est possible de réaliser quelques tests unitaires ou d’intégration pour s’assurer que tout est bien connecté.
2 - Le besoin de lecture diffère du besoin d’écriture
Dans le cas de besoins de lecture et/ou d’écriture en base massifs, il est fortement recommandé d’implémenter le pattern Command & Query Responsibility Segregation (CQRS). Ce pattern a la particularité de nécessiter 2 styles architecturaux différents, et donc deux stratégies de tests adaptées à ces styles.Le style approprié à la "command", c’est-à-dire l’écriture, s’approche d’une architecture hexagonale, et devrait suivre une stratégie de test en pyramide. Quant à celui dédié à la "query", c’est-à-dire la lecture, une architecture 2 couches (contrôleur / data access) semble plus propice, avec cette fois-ci une stratégie de test en pyramide inversée.
3 - Le besoin de conserver chaque changement d’état
Si votre application répond à des besoins de transactions financières ou encore d’analyser de rejouer et déjouer une action (comme dans le cas d’un article ajouté puis supprimé d’un panier d’un site e-commerce), l’event-sourcing est l’architecture préconisée.Un event store servira à enregistrer tous les événements. L’événement final reposera sur le rejeu de tous les événements dans l’ordre. La stratégie de test associée à l’event sourcing est la pyramide de tests.
4 - Le besoin de découper ou de réutiliser une fonctionnalité
Si vous souhaitez réutiliser un service ou encore gagner en autonomie et fluidifier la mise en production, vous pouvez opter pour une architecture microservices. Notons que chaque microservice aura sa propre typologie et que par conséquent, l’architecture applicative recommandée pour chacun des services en dépendra. Il en va de même pour la stratégie de test associée. Pour tester l’ensemble des services, vous pouvez :
- Définir un contrat d’interface : entre un provider et un consumer. Les tests automatisés seront isolés et écrits de part et d’autre du contrat. Le principal inconvénient : difficile de s’assurer que l’ensemble fonctionne correctement.
- Définir un contract testing : écrire un fichier avec des types de données et des jeux d’essais. La solution peut être menée par le consumer (solution “Pact”) ou par le provider (solution “Spring Cloud Contract” ). Elle peut également être bi-directionnelle (solution “Pactflow”). Le principal inconvénient : impossibilité de paralléliser les tâches.
- Définir un contrat exécutable : la solution Specmatic vous permet de créer automatiquement un serveur pour le consumer et un ensemble de tests automatisés pour le provider.
5 - Le besoin de valider un concept, avant de se lancer
Comme son nom l’indique, le POC (Proof Of Concept) sert à valider un concept; il n’est pas voué à aller en production. C’est le seul cas pour lequel une architecture spaghetti sera autorisée : l’idée étant de ne pas investir sur la structure ou sa stratégie de test associée. Par conséquent des tests manuels seront suffisants pour s’assurer du bon fonctionnement d’un POC.
Conclusion
Vous l’aurez donc compris, à chaque contexte, son architecture et sa stratégie de test associée.
Mes impressions
Le tableau des stratégies de test recommandées pour chaque contexte résume bien le talk. Je retiens surtout qu’il existe d’autres alternatives à la pyramide des tests !
Bonus : Culture TEST
Les 3 volumes « Culture TEST » co-écrits avec Sylvie Ponthus-Violland et Stéphane Bedeau sont disponibles ici.