Résumé

  • Les tests générés visent le code modernisé ; la documentation précise qu’ils ne valident pas la conservation des fonctions du code d’origine.
  • Tests existants portés, nouveaux tests, vérification locale et recette en fonctionnement ne constituent pas une seule preuve.

Une migration peut livrer davantage de tests sans avoir réglé la question la plus importante : qui décide que le logiciel fait encore ce que son client attend ? La génération de tests unitaires annoncée par AWS Transform pour .NET le 10 septembre facilite un travail concret. L’outil évalue la testabilité, prépare la couverture et écrit des tests pour des classes adaptées, dont la logique métier et les contrôleurs. Cette option est proposée dans AWS Toolkit for Visual Studio. Sa valeur dépend toutefois de la preuve qu’on lui demande de fournir.

Le guide des tests unitaires fixe une limite nette : les tests sont générés après modernisation et ne valident pas le maintien des fonctions du code initial dans le nouveau code. Ils peuvent enrichir la protection contre des régressions futures sans reconstituer les attentes historiques qui n’auraient jamais été consignées. Confondre ces deux bénéfices ferait glisser la recette.

Les tests déjà présents constituent une catégorie différente. Transform porte les projets MSTest, NUnit et xUnit pris en charge, les exécute et en restitue les résultats. Des attentes précédemment écrites peuvent ainsi être vérifiées sur le code transformé. Cela ne rend pas l’ancienne suite exhaustive et ne garantit pas que chaque situation métier y figure. Les nouveaux tests ajoutent des éléments ; leur nombre ne leur donne pas l’antériorité d’une référence.

Le moment choisi pour les générer change également la portée du contrôle. Activés au début du travail, ils sont inclus dans la vérification locale de compilation. Demandés en mode interactif après transformation, ils ne font pas partie de cette étape déjà terminée. Cette seconde possibilité autorise des modifications du code avant de produire les tests. Elle ne signifie pas qu’ils ne pourront jamais être exécutés, mais qu’une validation précédente ne couvre pas rétroactivement leur arrivée.

Le dossier de livraison devrait donc identifier l’origine des tests et la révision examinée. Quels contrôles ont été portés, lesquels viennent d’être rédigés, quel code a réellement été vérifié et quelles tâches restent ouvertes ? Un total unique de tests réussis masque facilement ces différences. Une mesure de couverture ne décide pas, à elle seule, si les résultats attendus répondent aux exigences du client.

Les recommandations avant transformation demandent d’ailleurs un plan de validation couvrant le comportement, l’apparence, la sécurité, la logique métier et le stockage des données. Elles distinguent aussi la modernisation .NET d’une refonte d’architecture. L’automatisation des tests ne devrait ni élargir implicitement la promesse achetée ni faire disparaître un travail de vérification prévu.

Enfin, le guide de finalisation demande de lire les rapports, de lancer l’application et de comparer fonctions et interface avec l’original. Ce n’est pas une formalité après un indicateur favorable : c’est le lien entre des fichiers livrés et un service accepté. Le lancement ne démontre ni une migration de production achevée ni un gain mesuré de temps de recette ou de qualité.