Réponse.

L’automatisation des tests de la logique métier dans des applications complexes a une longue histoire, depuis les premiers scripts de validation jusqu’aux tests modernes de microservices. À mesure que les architectures se sont complexifiées (monolithique, SOA, micro- et macroservices), un problème est apparu : les modifications à un niveau d’architecture cassent souvent les tests à d’autres niveaux.

Problème : il est nécessaire d’écrire des tests qui sont résistants à la réorganisation des interactions entre les couches de l’application : changements de contrats, de structures de données, de processus métier. Souvent, les tests sont liés aux détails de l'implémentation, ce qui les rend "fragiles" et difficiles à maintenir.

Solution : construire les tests selon le principe de "boîte noire" en se concentrant sur les données d'entrée/sortie, utiliser des couches d’abstraction pour accéder aux entités du système (par exemple, Service Layer et Domain Layer dans l’architecture). Il est vital de dissocier la logique métier des détails d’infrastructure et d’utiliser des mocks/stubs pour les dépendances externes, afin d’assurer l’isolement et la stabilité des tests.

Caractéristiques clés :

Accent sur le test des contrats : vérification des invariants métier indépendamment des implémentations internes.
Utilisation de couches d’abstraction pour accéder à la logique (par exemple, Application Service → Domain Service → Repository).
Introduction de mvp/mocks/stubs pour la reproductibilité et l’isolement de l’environnement de test.

Questions pièges.

Quelle est la différence entre vérifier la logique métier via la couche UI et vérifier via l’API/Domain Layer ?

Les tests UI sont souvent moins résistants aux changements car les moindres modifications de l'interface entraînent des échecs de test. Les tests via l’API ou la Domain Layer dépendent moins du frontend et isolent mieux la vérification des règles métier.

Faut-il mocks toutes les dépendances de la logique métier pour les tester ?

Non ! Il ne faut pas mocker ce qui peut être réalisé dans l’environnement de test (par exemple, une mémoire légère plutôt qu'une base de données). Les mocks sont nécessaires pour les dépendances complexes, coûteuses ou externes. Un mockage complet peut mener à des tests "fictifs" qui ne reflètent pas les scénarios réels.

Les tests de seulement scénarios positifs sont-ils suffisants pour la logique métier ?

Non ! Il est important de couvrir tous les cas extrêmes et les scénarios négatifs, sinon des erreurs critiques passeront inaperçues, entraînant des vulnérabilités dans le processus métier principal.

Erreurs typiques et anti-patterns

Liaison des tests à des objets/structures internes, sélecteurs fragiles.
Absence de chemins négatifs/alternatifs.
De nombreux tests redondants avec de petites variations.

Exemple de la vie réelle

Cas négatif

Dans le projet, la logique métier était testée uniquement via des tests UI Selenium, en travaillant directement avec des boutons et des formulaires. Chaque refactoring du frontend entraînait une chute massive des tests automatisés.

Avantages :

Couverture rapide de l’ensemble des fonctionnalités
Facilité d'explication des scénarios à la direction

Inconvénients :

Fragilité : le moindre changement de l’interface casse tout
Tests lents, instables, difficiles à maintenir

Cas positif

Dans le projet, une couche de tests API et unitaires a été mise en place. L'UI couvrait uniquement les chemins critiques, toute la validation restante se faisait via le niveau de service avec mockage des services coûteux.