Les outils de débogage par catégorie, et ce que chacun présuppose
Débogueurs pas à pas et inspecteurs
Mettre l'exécution en pause et observer l'état.
Présuppose que vous savez déclencher la défaillance à la demande.
Journaux et traçage
Voir après coup ce qui s'est passé, y compris en production.
Présuppose que vous avez journalisé la bonne information au préalable.
Profileurs
Trouver où passent le temps ou la mémoire.
Présuppose que le problème est bien lié aux ressources.
Tous présupposent que vous êtes déjà parvenu jusqu'à la défaillance. C'est précisément dans ce présupposé que passent les heures.
L'étape manquante
Une reproduction fiable est l'artefact le plus précieux du débogage, et celui qui a le moins de chances d'exister. Sans elle, vous devinez ; avec elle, tous les autres outils deviennent immédiatement efficaces.
Ce qui rend une reproduction fiable, c'est qu'elle est consignée sous forme d'étapes avec un résultat attendu, et non conservée dans la tête de quelqu'un. Une fois écrite, elle peut être rejouée, transmise à quelqu'un d'autre et conservée après le correctif.
Pourquoi cela compte encore plus avec un agent de codage
Quand c'est un agent qui corrige, une description vague est bien plus pénalisante que pour un humain. Une personne peut deviner ce que vous vouliez dire à partir d'une capture d'écran. Un agent, lui, a besoin que la séquence et l'écart constaté soient énoncés explicitement ; à défaut, il corrigera la mauvaise chose avec assurance.
Dans quel ordre procéder
Face à un bug que vous ne savez pas expliquer d'emblée, il existe un enchaînement qui converge plus vite que le fait de suivre votre première hypothèse, surtout parce que votre première hypothèse porte en général sur le code alors que la réponse, souvent, ne s'y trouve pas.
Le problème se produit-il à partir d'un état totalement vierge ? Si non, il s'agit d'un état résiduel et rien dans le code n'est faux de la manière dont vous l'imaginez.
Se produit-il dans un autre environnement ? Si non, c'est la différence entre les environnements qui constitue le bug, et vous pouvez arrêter de relire le diff.
Se produit-il à chaque fois ? Si non, c'est une question de timing ou de concurrence, ce qui écarte la plupart des explications déterministes que vous vous apprêtiez à tester.
Trois questions, quelques minutes, et chaque réponse élimine toute une classe de causes. L'essentiel du temps consacré au débogage sert à explorer une classe que l'une de ces questions aurait écartée d'emblée.
Conservez la reproduction ensuite
Le cas que vous avez construit pour observer le bug est le contrôle qui l'empêche de revenir. La plupart des équipes le suppriment en même temps que la branche : c'est pour cela que le même défaut réapparaît six mois plus tard sans que personne ne le reconnaisse.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
La même configuration est disponible dans le tableau de bord TestSprite si vous préférez ne rien installer en local. Le reste des commandes CLI se trouve dans le dépôt CLI.
La GitHub App est un webhook que vous configurez dans le tableau de bord TestSprite. Il écoute l'événement de déploiement que votre pipeline produit déjà, de sorte que rien ne change dans votre dépôt.
GitHub Actions place cette étape à l'intérieur de votre propre workflow, configuré depuis le terminal.
Comment TestSprite fournit l'étape manquante
TestSprite transforme une reproduction en artefact. Vous décrivez la séquence et ce qui doit être vrai à la fin, puis l'outil s'exécute contre votre application déployée et rapporte ce qui s'est réellement passé. C'est l'étape que tous les autres outils de débogage supposent que vous possédez déjà.
L'installation ajoute la capacité de vérification à votre agent de codage, pour qu'il puisse produire et lire ces preuves lui-même au lieu d'attendre que vous les lui transmettiez. Pour un bug intermittent, exécuter plusieurs fois le même cas vous donne un taux d'échec, ce qui circonscrit la cause bien plus vite qu'une hypothèse de plus.
Et la reproduction survit au correctif. Elle reste dans le projet et s'exécute à chaque modification : le même défaut ne peut donc pas réapparaître discrètement une fois la branche fusionnée et la conversation disparue.
Quel est l'outil de débogage le plus sous-estimé ?
Une reproduction écrite. Elle coûte cinq minutes et rend tout le reste efficace.
Comment déboguer un problème intermittent ?
Exécutez plusieurs fois la même séquence et notez le taux. Un échec sur quatre relève en général du timing ou d'un état résiduel, ce qui restreint considérablement le champ.
Les journaux suffisent-ils ?
Ils vous disent ce que le code a décidé, pas ce que l'utilisateur a vécu. C'est dans l'écart entre les deux que se loge une grande partie des défauts.
Un agent peut-il déboguer à ma place ?
Il peut proposer des causes et des correctifs. Il ne peut pas observer l'application en cours d'exécution à moins que quelque chose ne lui en donne la capacité, et c'est justement l'étape qui manque à la plupart des configurations.
Que faire en premier face à un nouveau bug ?
Le reproduire et consigner la séquence. Tout ce qui suit va plus vite, y compris demander de l'aide à quelqu'un d'autre.
La reproduction, c'est l'outil.
Les outils de débogage supposent que vous savez déjà déclencher la défaillance, et c'est pour y parvenir que le temps passe. Consignez la reproduction par écrit, conservez-la après le correctif, et donnez à la personne qui corrige la séquence et l'écart constaté plutôt qu'une description.