Imaginez que vous soyez un chef ayant cuisiné avec un ensemble d'ustils de cuisine très anciens et rigides pendant des années. Ces outils fonctionnent très bien, mais ils sont lourds, nécessitent un format de recette spécifique et sont un peu encombrants. Soudain, un nouvel ensemble d'outils modernes, légers et flexibles arrive sur le marché. Tout le monde s'accorde à dire que les nouveaux outils permettent de cuisiner plus vite et de façon plus savoureuse, mais passer à l'un ou l'autre est un cauchemar. Vous ne pouvez pas simplement jeter les anciens outils ; vous devez traduire soigneusement chaque recette que vous avez écrite pour qu'elle fonctionne avec le nouvel équipement.

C'est exactement la situation à laquelle les programmeurs Python sont confrontés avec leurs outils de test.

Le Problème : Deux cuisines, un livre de recettes

Dans le monde de la programmation Python, il existe deux manières principales d'écrire des « recettes de test » (du code qui vérifie si un logiciel fonctionne correctement) :

1. unittest : L'outil de la vieille école. Il fait partie du kit de cuisine standard. Il est strict ; vous devez écrire vos tests à l'intérieur de classes spéciales (comme mettre chaque recette dans un classeur spécifique) et utiliser des commandes longues et spécifiques pour vérifier si les choses sont correctes.
2. pytest : L'outil moderne et populaire. Il est plus léger et plus flexible. Vous pouvez écrire des tests sous forme de simples fonctions (comme des fiches de recettes volantes), et il utilise des commandes plus courtes et plus propres.

Parce que pytest est bien plus agréable à utiliser, de nombreux projets de logiciels veulent passer de unittest à pytest. Cependant, le faire manuellement revient à traduire toute une bibliothèque de livres de cuisine à la main. Cela prend un temps infini et il est facile de commettre des erreurs.

La Solution : Un « Livre de Recettes de Migration »

Les auteurs de ce document, Altino Alves et Andre Hora, ont réalisé que pour construire un robot (ou une IA) capable de faire cette traduction automatiquement, ils avaient d'abord besoin d'une immense bibliothèque d'exemples montrant comment les humains procèdent réellement.

Ils ont créé TestMigrationsInPy.

Considérez ce jeu de données comme un immense livre de cuisine annoté contenant 923 exemples réels de développeurs ayant réussi à basculer leurs recettes de test du vieux style vers le nouveau style.

Comment ils ont fabriqué le livre de cuisine

Ils n'ont pas simplement deviné ; ils ont entrepris une chasse au trésor numérique :

1. Le Détecteur : Ils ont utilisé un outil intelligent pour scanner l'historique de 100 des projets Python les plus populaires (comme les célèbres bibliothèques Pandas et Flask). Ils ont recherché des messages de « commit » spécifiques où les développeurs disaient explicitement : « Je suis en train de changer ce test de unittest vers pytest ».
2. Le Filtre : Parfois, lorsque les développeurs mettent à jour du code, ils corrigent des bugs ou ajoutent de nouvelles fonctionnalités en même temps qu'ils changent d'outils. Cela crée des changements « emmêlés » qui sont confus à étudier. Les auteurs ont passé ces changements au crible manuellement et n'ont sélectionné que les migrations « pures » — des cas où le développeur a uniquement changé le style de test sans rien faire d'autre.
3. Le Résultat : Ils ont obtenu 923 exemples propres et isolés de ces changements.

Ce que contient le livre de cuisine

Le jeu de données est organisé comme une archive numérique. Pour chaque exemple, vous obtenez :

• L'image « Avant » : Le code de test écrit dans l'ancien style unittest.
• L'image « Après » : Le même code de test réécrit dans le nouveau style pytest.
• L'étiquette de « Type » : Une étiquette indiquant quel genre de changement a eu lieu.

Les auteurs ont identifié deux types principaux de changements, qu'ils comparent à différents niveaux de difficulté :

• Échanges simples (La migration d'« Assertion ») : C'est comme changer une mesure de « tasses » en « grammes ». C'est direct. Par exemple, changer une commande longue comme self.assertEqual(a, b) par un simple assert a == b.
• Réécritures complexes (La migration de « Fixture ») : C'est comme réaliser que votre ancienne recette nécessitait une étape de préchauffage du four spécifique, mais que le nouveau four fonctionne différemment. Vous devez restructurer complètement la préparation des ingrédients. Dans unittest, vous pourriez avoir une méthode setup qui s'exécute avant chaque test. Dans pytest, cela se transforme en une « fixture » — une fonction d'aide réutilisable. Parfois, une seule méthode setup ancienne doit être divisée en quatre différentes nouvelles fixtures. C'est beaucoup plus difficile à automatiser.

Pourquoi est-ce important ?

L'article soutient que ce jeu de données est une « vérité terrain » (un manuel de référence parfait) pour les chercheurs.

Imaginez que vous essayiez de construire un assistant IA (comme un robot chef super intelligent) pour aider les développeurs à changer d'outils. Vous ne pouvez pas simplement dire au robot : « Allez changer ces tests ». Vous devez lui montrer des exemples.

• Usage 1 : Les chercheurs peuvent utiliser ce jeu de données pour entraîner des modèles d'IA (comme les Large Language Models) à apprendre comment traduire du code automatiquement.
• Usage 2 : Ils peuvent tester si leur nouvelle IA est douée pour les « échanges simples » par rapport aux « réécritures complexes ».

Les auteurs ont même testé cela eux-mêmes avec un modèle d'IA puissant (GPT-4o). Ils ont constaté que l'IA était plutôt bonne pour les échanges simples, mais qu'elle avait parfois besoin de l'aide humaine pour les changements de fixtures complexes, prouvant que si l'IA peut accélérer les choses, elle n'est pas encore parfaite.

L'essentiel

Cet article ne prétend pas avoir construit le robot parfait qui effectue la migration pour vous aujourd'hui. Au lieu de cela, il a construit le manuel de formation (le jeu de données) qui permet aux chercheurs de construire ce robot. Il fournit une collection claire et vérifiée de 923 exemples réels de la manière de passer du vieux style de test encombrant au nouveau style élégant, aidant ainsi la communauté logicielle à automatiser ce processus fastidieux à l'avenir.