Réponse.

L'automatisation des tests du code legacy est l'un des plus grands problèmes classiques dans le domaine de l'IT.

Historique de la question : De nombreuses entreprises sont confrontées à la nécessité de tester des systèmes qui ont été écrits sans tenir compte de l'automatisation future. Souvent, ces projets ont une documentation faible, une dette technique élevée et un manque de composants isolés.

Problème : Les principales difficultés surviennent à cause de

l'absence de hooks de test et de points d'intégration
l'impossibilité d'isoler les données pour les tests
une forte interdépendance des modules
un grand nombre d'anomalies et de changements non reflétés dans le code

Solution : En général, le processus se déroule étape par étape :

Analyse du système : il est nécessaire de déterminer les processus métier critiques et de convenir de la portée des tests automatiques.
Implémentation des points de test : autant que possible, une partie du code est enveloppée dans des proxies, adaptée pour des doublures de test ou utilise le pattern d'injection de dépendance.
Couverture progressive par des tests automatiques : on commence par écrire des tests pour le code "le plus simple" et le moins lié.
Support et refactoring constants : après l'ajout des tests, on les utilise comme un filet de sécurité pour des améliorations.

Caractéristiques clés :

Les tests commencent souvent non par zéro, mais par des "enveloppements" autour des fonctions existantes.
Il est nécessaire d'ajouter progressivement la testabilité à l'architecture.
L'entreprise doit être aussi impliquée que possible dans la réglementation des scénarios critiques.

Questions pièges.

Peut-on commencer à écrire des tests automatiques avant de refactoriser complètement le code legacy ?

Oui, souvent les tests automatiques sont nécessaires pour sécuriser le refactoring. Il ne faut pas attendre une "idéalité" complète - au contraire, les tests aident à apporter des changements en toute confiance.

Faut-il essayer de couvrir tout le code legacy par des tests automatiques ?

Non. Il faut se concentrer sur les scénarios les plus risqués et les plus utilisés. Couvrir "tout ce qui existe" nuit à la vitesse et n'a pas de sens.

Est-il obligatoire d'implémenter des patterns modernes tels que DI pour tester le code legacy ?

Non, mais ils sont recommandés si les ressources le permettent. La première étape est au moins une isolation partielle, des mocks et des points de test spéciaux dans le code.

Erreurs typiques et anti-patterns

Migration de tout le code à la fois pour des tests automatiques - les projets s'arrêtent et perdent leur sens business.
Couverture "paranoïaque" de fonctions peu significatives.
Absence de communication entre développement, tests et business.

Exemple de la vie

Cas négatif

L'équipe a tenté d'implémenter des tests automatiques en réécrivant toute l'ancienne application selon les patterns SOLID et en couvrant 100% du code par des tests.

Avantages :

Amélioration architecturale de base.
À long terme, les tests peuvent être bénéfiques.

Inconvénients :

Blocage du développement pendant plusieurs mois.
Bugs constants et désynchronisation avec les exigences de l'entreprise.
Perte de pertinence du code au moment où les tests sont écrits.

Cas positif

Des tests automatiques ont été implémentés uniquement pour les points clé de calculs, avec la mise en place de stubs spéciaux, en modifiant au minimum le code global.