Les changements qui touchent à la fois les tests et le code sont annulés moins souvent que les changements de code seul de taille comparable

Hypothèse

Les dépôts enregistrent leurs propres remises en question : la documentation de git-revert la décrit comme l'enregistrement de nouveaux commits qui annulent l'effet de commits antérieurs, et les commits correctifs font souvent référence, dans leur message, au changement qu'ils corrigent. L'hypothèse est que, parmi des changements de taille comparable dans une même zone d'une base de code, ceux qui ajoutent ou modifient des fichiers de test en même temps que le code de production sont annulés ou corrigés dans une courte fenêtre moins souvent que les changements ne touchant que le code de production. Le mécanisme proposé n'est pas que les tests détectent chaque bogue, mais qu'écrire ou ajuster un test oblige la personne qui écrit le code à énoncer ce que le changement doit faire et à l'exécuter une fois sous cette forme, ce qui élimine avant la relecture toute une catégorie d'erreurs (mauvaise branche, valeur par défaut erronée, point d'appel oublié).

Prédiction

Pour un dépôt doté d'une suite de tests fonctionnelle, la proportion de changements suivis, dans une fenêtre définie (par exemple 14 jours), d'une annulation de ce changement ou d'un commit dont le message le désigne comme corrigé, est plus faible pour les changements incluant des modifications de fichiers de test que pour les changements de code seul, après appariement sur les lignes modifiées, les fichiers touchés et le répertoire. L'écart devrait être plus faible pour les changements triviaux (renommages, modifications de commentaires) et plus important pour les changements touchant une logique avec des branchements. Les changements qui ne touchent que des fichiers de test sont exclus des deux groupes.

Test proposé

1. Sélectionner des dépôts dotés d'une suite de tests s'exécutant en intégration continue et d'un historique d'au moins un an ; définir les fichiers de test par motif de chemin, propre à chaque dépôt.
2. Pour chaque changement qui n'est pas une fusion, enregistrer la taille, les fichiers, le répertoire, si des fichiers de test ont été modifiés, et l'identité de l'auteur.
3. Identifier les changements « regrettés » : un git revert ultérieur du changement, ou un commit dans la fenêtre dont le message référence l'identifiant du changement avec une formulation évoquant une correction ; consigner la règle de détection utilisée.
4. Apparier les changements de code seul et les changements de code plus tests sur la taille et le répertoire ; comparer les taux de « regret » avec un intervalle, et répéter l'analyse par dépôt plutôt que de regrouper les données.
5. Rapporter la proportion de changements qui ont touché des tests, quels qu'ils soient, car un dépôt où presque chaque changement le fait n'offre aucun contraste.

Statut

Aucun résultat n'est revendiqué. Les annulations constituent un signal restreint : de nombreux mauvais changements sont corrigés en avançant, sans aucune référence, et certaines annulations n'ont rien à voir avec des défauts (une fonctionnalité retirée pour des raisons produit). L'appariement sur la taille est essentiel, car les changements plus volumineux sont à la fois plus susceptibles d'inclure des tests et plus susceptibles d'être annulés, ce qui pourrait produire un résultat artefactuel dans un sens comme dans l'autre.