What Do Contribution Guidelines Say About Software Testing?

Imaginez les projets de logiciels open source comme de vastes cuisines communautaires en pleine effervescence. N'importe qui peut entrer, prendre un couteau et commencer à couper des légumes (écrire du code) pour aider à préparer un meilleur repas. Mais pour que la cuisine fonctionne sans accroc, les chefs de cuisine (les mainteneurs du projet) laissent un Livret de règles sur le comptoir. Ce Livret explique aux nouveaux aides comment se laver les mains, où trouver les ingrédients et comment soumettre leurs légumes découpés sans gâcher la soupe.

Ce document est comme une équipe de chercheurs qui est entrée dans 200 de ces célèbres cuisines communautaires (plus précisément celles utilisant les langages Python et JavaScript) pour lire les Livrets de règles et voir ce qu'ils disent réellement sur les tests.

Dans le monde de la cuisine, le « test » revient à goûter le plat avant de le servir pour s'assurer qu'il n'a pas un goût de savon. Les chercheurs voulaient savoir : Les Livrets de règles enseignent-ils réellement aux nouveaux aides comment goûter la nourriture, ou supposent-ils simplement que tout le monde sait déjà le faire ?

Voici ce qu'ils ont trouvé, présenté simplement :

1. La plupart des cuisines ont une section « Goût » (mais pas toutes)

Les chercheurs ont découvert que 78 % des cuisines avaient une section spécifique dans leur Livret de règles dédiée à la dégustation (le test).

• Où se trouve-t-elle ? La plupart du temps (58 %), elle se trouve dans un fichier nommé littéralement « CONTRIBUTING » (le manuel d'instructions principal). Parfois, elle se trouve dans une brochure séparée et plus sophistiquée (documentation externe), et plus rarement, elle est simplement griffonnée sur le menu principal (README).
• Le fossé : Environ 22 % des cuisines n'avaient aucune instruction sur la dégustation. Si vous entriez dans ces cuisines, vous devriez deviner par vous-même comment vérifier si votre nourriture est bonne.

2. Le déséquilibre du « Comment faire » : Exécuter vs Écrire

Lorsque les Livrets de règles parlaient de dégustation, ils étaient très bons pour une chose, mais mauvais pour une autre.

• Le « Comment exécuter » (83,5 %) : La plupart des Livrets de règles disaient clairement : « Voici l'incantation magique (commande) pour goûter toute la marmite ». C'est comme dire : « Appuyez sur ce bouton pour vérifier la saveur ».
• Le « Comment écrire » (37 %) : Beaucoup moins de Livrets de règles expliquaient comment créer un nouveau test de goût. C'est comme dire : « Appuyez sur le bouton », mais sans vous apprendre comment fabriquer une nouvelle cuillère ou comment savoir à quoi ressemble une « mauvaise » saveur.
• Le résultat : Les aides savent comment vérifier la nourriture existante, mais ils sont souvent laissés à eux-mêmes pour découvrir comment créer leurs propres tests pour les nouveaux ingrédients qu'ils ont ajoutés.

3. Le problème de la « Pyramide des tests »

Dans le logiciel, il existe différents niveaux de tests, comme différents types de tests de goût :

• Tests unitaires (71 %) : Ce sont comme goûter un seul ingrédient (ex : « Est-ce que cette carotte est sucrée ? »). Les Livrets de règles en parlaient beaucoup.
• Tests d'intégration (20,5 %) : C'est comme goûter comment la carotte et l'oignon travaillent ensemble dans la marmite. Les Livrets de règles mentionnaient rarement cela.
• Tests de bout en bout (15,5 %) : Cela revient à goûter le repas final, entièrement cuit, pour voir si tout le plat fonctionne. Les Livrets de règles n'en parlaient presque jamais.

La métaphore : Les chefs sont très inquiets de savoir si les carottes ont le bon goût, mais ils disent rarement aux aides comment vérifier si tout le ragoût va brûler ou si les saveurs se mélangent bien.

4. Les « Armes Secrètes » manquantes

Les chercheurs ont également cherché des conseils de cuisine avancés qui aident à rendre les tests plus faciles et plus fiables :

• Le Mocking / Simulation (9,5 %) : Parfois, on ne peut pas goûter la vraie eau de mer dans notre soupe ; il faut utiliser un faux salier pour simuler l'expérience. C'est ce qu'on appelle le « mocking ». Seulement 1 cuisine sur 10 proposait des instructions sur l'utilisation de ces outils de simulation.
• La Couverture / Coverage (25,5 %) : C'est un score qui montre quelle partie de la recette a été réellement goûtée. Seulement environ un quart des cuisines indiquaient aux aides quel score ils devaient viser.
• Les Bonnes Pratiques (9 %) : Des conseils généraux comme « Toujours goûter avant de servir » étaient très rares.

Conclusion

Le document conclut que, bien que la plupart des projets open source veuillent que leurs aides testent leur travail, les instructions laissées derrière elles sont déséquilibrées.

Ils sont excellents pour dire : « Voici comment lancer le test », mais ils sont souvent silencieux sur :

• Comment écrire un nouveau test.
• Comment tester des interactions complexes (intégration).
• Comment tester l'ensemble du système (bout en bout).
• Comment utiliser des outils avancés (mocking) ou fixer des objectifs de qualité (couverture).

À retenir : Si vous êtes un nouvel aide dans l'une de ces cuisines, vous saurez peut-être appuyer sur le bouton « goûter », mais vous pourriez être laissé seul pour découvrir comment réellement créer un test de goût pour votre nouvelle recette, ou comment vous assurer que votre nouveau plat ne va pas gâcher tout le repas. Les auteurs suggèrent que les chefs de projet doivent rédiger des instructions plus claires et plus complètes afin que les aides n'aient pas à deviner.