Partie 2 – Vers des Tests Efficaces et une Architecture Testable

Après avoir vu pourquoi et comment viser la qualité dans la conception logicielle, penchons-nous à présent sur la testabilité et la structure du code. L’objectif : disposer de tests fiables, rapides, et directement alignés sur les règles métier. Dans cette optique, nous aborderons la question du découplage, de l’inversion de dépendances et de la classification des tests (unitaires, intégration, end-to-end).

Les tests manuels, souvent perçus comme un mal nécessaire, finissent par peser lourd sur les équipes :

• Répétitifs et lents : Chaque déploiement requiert les mêmes validations, effectuées à la main.
• Sources d’erreurs : L’humain n’est pas infaillible, et certains scénarios sont difficiles à reproduire exactement.
• Manque de fiabilité : Plus l’application est complexe, plus il est probable d’oublier un cas particulier ou de bâcler un test.

La solution réside dans l’automatisation. Ainsi, chaque nouveau développement est accompagné de tests qui peuvent être rejoués à l’infini pour détecter toute régression.

Il est utile de distinguer deux grandes catégories de fonctionnalités :

1. Les Queries : Elles extraient ou affichent des informations (lecture).
2. Les Commandes : Elles modifient l’état du système (écriture).

Pour tester efficacement, il faut comprendre ce que l’on vérifie :

• Dans le cas d’une Query, on s’assure que la donnée retournée est correcte.
• Dans le cas d’une Commande, on vérifie l’impact sur l’état interne de l’application (par exemple, la création d’un nouvel événement).

En software craftsmanship, on recommande une architecture qui facilite les tests :

• Logique métier au centre : On sépare clairement la partie métier (règles, comportements) du reste (framework, base de données).
• Inversion de dépendances : Le cœur définit des contrats (interfaces) qu’implémentent les éléments externes (base de données, API). Ainsi, on peut substituer la base réelle par un fake ou un mock en test.
• Mode boîte noire : Tester l’application via ses ports publics (API, services) sans dépendre des détails internes. Un refactoring structurel n’impacte alors pas la majorité des tests.

Le test unitaire couvre un scénario métier précis, souvent articulé autour d’une commande (action) ou d’une query. Il suit en général la structure AAA :

1. Arrange : Préparer l’état initial, configurer les dépendances et données nécessaires.
2. Act : Appeler la fonction ou la méthode testée.
3. Assert : Vérifier le résultat (sortie, état, log).

L’intérêt d’un test unitaire est qu’il reste rapide, isolé et fiable. Les retours négatifs ou positifs sont immédiats, ce qui encourage la pratique du TDD (Test-Driven Development) ou, au minimum, l’écriture de tests systématiques.

Un test unitaire efficace suit l’acronyme F.I.R.S.T. :

• Fast : Exécution en millisecondes ou secondes, afin d’itérer souvent.
• Indépendant : Chaque test ne dépend pas d’un autre, évitant les effets de bord.
• Repeatable : Les résultats sont constants, sans influence extérieure (hasard, réseau, etc.).
• Self-Validating : Le test se juge lui-même, sans inspection humaine.
• Thorough : Il couvre clairement le scénario qu’il vise à vérifier.

On appelle “test doubles” l’ensemble des objets qui remplacent des composants réels lors de l’exécution des tests. Parmi eux :

• Dummy : Vide, utilisé uniquement pour satisfaire une signature de méthode.
• Stub : Renvoie des valeurs préconfigurées, sans logique particulière.
• Spy : Enregistre les interactions (ex. nombre d’appels).
• Mock : Combine stub et spy, parfois trop couplé à l’implémentation interne.
• Fake : Une version simplifiée mais complète d’un composant (par ex. base de données en mémoire).

L’objectif est de contrôler l’environnement pour éviter toute variation ou lenteur. Par exemple, si votre code appelle un API externe, remplacez-la par un stub renvoyant la réponse désirée ; ainsi, votre test reste rapide et déterministe.

Pour garder des tests lisibles, on utilise souvent :

• Object Mother : Fonctions comme createEvent("titre", "2025-03-15") pour générer des objets courants.
• Builder : API fluide permettant de configurer au besoin les attributs principaux, sans avoir à surcharger le test lui-même de paramètres secondaires.

L’essentiel est de simplifier la création d’objets dans vos tests, afin de se concentrer sur le scénario et la lisibilité des intentions.

• Test unitaire : Vérifie la logique métier pure, sans accès réel à la base ou au réseau.
• Test d’intégration : Vérifie un composant (ex. un repository) en condition réelle ou semi-réelle.
• Test end-to-end (E2E) : Parcourt l’application dans son ensemble, depuis l’interface utilisateur jusqu’à la base de données.

La règle d’or est de ne pas abuser des tests E2E, qui sont longs et fragiles. Miser sur une majorité de tests unitaires (rapides, simples à maintenir) complétés par quelques tests d’intégration et E2E ciblés pour valider les chemins critiques.

L’architecture hexagonale, dite Ports & Adapters, propose de séparer :

• User side : Interfaces, API, éléments déclencheurs de la logique métier.
• Data side : Base de données, services externes, etc.
• Cœur métier : Ne dépend que des ports, c’est-à-dire des contrats définis par lui-même.

Cette disposition rend le cœur aisément testable. Si vous avez besoin d’intégrer un nouvel outil ou un nouveau service, vous créez un adaptateur, sans toucher au noyau. En test, il est ainsi simple de remplacer un adaptateur par un fake, un stub ou un mock.

En optant pour une architecture modulaire et un usage massif de tests automatisés, l’équipe gagne en sérénité et en productivité. Chaque nouvelle fonctionnalité est validée presque instantanément, et les régressions sont détectées tôt. Les développeurs peuvent évoluer rapidement, sachant que leur pipeline de tests veille à la cohérence du système.

Le software craftsmanship trouve ici sa concrétisation : produire un code de haute qualité, maintenable, au service d’une livraison continue de valeur. En s’appuyant sur des pratiques éprouvées – TDD, inversion de dépendances, tests unitaires – on parvient à donner vie à un écosystème logiciel capable de s’adapter aux changements, sans rompre sous la complexité ou la dette technique.

Ainsi se ferme la boucle initiée en Partie 1 : de la philosophie de l’artisanat logiciel à la pratique quotidienne des tests et de l’architecture hexagonale, le software craftsmanship nous encourage à viser l’excellence et à partager nos connaissances, pour le bénéfice de toute l’équipe et de nos utilisateurs finaux.