Quelles conventions de nommage des tests et d'organisation des fichiers aident quiconque à localiser le plus vite le comportement en échec ?

Question ouverte

Les frameworks de test ne fixent que la découverte. La documentation de pytest décrit la collecte des fichiers test_*.py ou *_test.py et des fonctions préfixées par test, et évoque des organisations où les tests se trouvent hors ou dans le paquet applicatif ; le paquet testing de Go exige des fonctions TestXxx dans des fichiers _test.go. Tout ce qui dépasse cela relève de la convention : nommer un test d'après la méthode (test_parse), d'après le comportement (test_parse_rejects_trailing_comma) ou par une phrase dans un bloc describe (« parse rejette une virgule finale ») ; faire correspondre les fichiers de test un à un avec l'arborescence source ou les grouper par fonctionnalité ou par scénario ; faire porter un test sur une seule assertion ou sur un seul comportement ; choisir où vivent les fixtures partagées et à quelle distance des tests qui les utilisent. Les équipes se disputent sur ces choix, et des agents fondés sur des modèles de langage naviguent désormais dans des suites qu'ils n'ont pas écrites, où ils doivent trouver le test qui couvre un comportement ou interpréter un échec à partir de son seul nom dans un journal d'intégration continue. Quelqu'un a-t-il mesuré quelles conventions raccourcissent le temps entre « ce test a échoué » ou « ce comportement doit changer » et « voici le bon test », pour des personnes ou pour des agents, et si faire correspondre l'arborescence source aide davantage qu'un groupement fondé sur le comportement une fois qu'une suite dépasse quelques centaines de tests ?

Ce qu'une réponse utile contient

Le langage et le framework ; la taille de la suite ; les conventions comparées, énoncées précisément (motif de nommage, organisation des répertoires, emplacement des fixtures, granularité des assertions) ; la tâche (diagnostiquer un échec à partir d'une ligne de journal, localiser les tests d'une fonction, ajouter un test pour une nouvelle règle) ; les participants (personnes développeuses découvrant le code, personnes en charge de la maintenance, agents avec des versions de modèle nommées) ; la mesure (temps, taux de réussite, taux de mauvais test) avec sa dispersion ; et des facteurs de confusion tels que la navigation dans l'EDI, l'outillage de couverture ou la recherche plein texte. Le retour d'une seule équipe ayant changé de convention est utile s'il précise ce qui a changé et ce qui a changé en même temps ; des enquêtes de préférence sans tâche associée doivent être signalées comme relevant de l'opinion.