Ce que le vibe testing supprime réellement
Il supprime l'étape de traduction. Habituellement, vous savez quel comportement vous voulez, puis vous passez une heure à le convertir en sélecteurs, en attentes et en assertions, dont la plus grande partie concerne le framework plutôt que votre produit. Décrire le comportement et laisser un agent se charger de la traduction conserve ce qui porte du sens et élimine ce qui n'en porte pas.
La deuxième chose qu'il supprime, c'est le coût de maintenance. Une étape exprimée comme une intention survit à une refonte qu'un sélecteur codé en dur ne supporterait pas, parce que l'intention reste vraie quand le bouton change de place.
Là où une vérification décrite dérape
Trop vague pour échouer
« Vérifier que le tableau de bord fonctionne » ne peut pas échouer, parce que rien de précis n'a été affirmé.
Nommez l'élément observable : quel nombre, quelle ligne, quel état.
Affirmer l'action
« Cliquer sur Enregistrer » est une étape, pas une vérification. Une exécution peut l'accomplir sans rien prouver.
Dites ce qui doit être vrai ensuite, et choisissez quelque chose qu'un rechargement de la page confirmerait.
Sujet ambigu
« L'utilisateur voit ses commandes » ne précise pas de quel utilisateur il s'agit, et c'est exactement là que se nichent les bugs de permissions.
Précisez à qui appartiennent les commandes, et vérifiez qu'une autre personne ne peut pas les voir.
L'habitude qui distingue les vraies vérifications des vérifications décoratives
Cassez volontairement ce qui est testé et confirmez que la vérification passe au rouge. Cela prend une minute et c'est la seule preuve que la vérification est reliée à quelque chose.
C'est encore plus important ici qu'avec des tests écrits à la main, parce qu'une vérification décrite laisse plus de place à une interprétation généreuse. Une exécution qui se termine sans jamais atteindre la moindre assertion n'est pas un succès, et le seul moyen de découvrir que vous en avez une est d'essayer de la faire échouer.
Pour commencer
L'installation ajoute cette capacité à votre agent de codage : les vérifications se décrivent et s'exécutent là même où le code s'écrit.
Rien de tout cela n'exige un terminal. Créez un projet dans le tableau de bord TestSprite, décrivez la vérification en langage courant et pointez-la vers votre application. Les développeurs de votre équipe peuvent piloter la même chose en ligne de commande s'ils le préfèrent ; tout se trouve dans le dépôt CLI.
Ce qu'il faut décrire en premier
Le parcours que vous montreriez en démo. S'il casse, vous l'apprendrez en public : il doit donc être couvert en premier.
Tout ce qui touche à l'argent ou aux permissions. Le coût d'une erreur y est maximal, et les deux échouent silencieusement.
La dernière chose qui a cassé. Ce qui vous a pris au dépourvu une fois mérite une vérification permanente, et vous savez déjà exactement comment la décrire.
Décrire une vérification qui tient la route
La différence entre une vérification qui vous protège et une vérification qui décore le pipeline tient presque toujours à la façon dont elle a été décrite, et ce schéma s'apprend.
Une bonne description comporte trois parties : un état de départ, une action, et un résultat observable ensuite qu'un rechargement confirmerait. « En tant qu'utilisateur connecté sans filtre enregistré, créez un filtre nommé Recent, rechargez la page et confirmez qu'il apparaît dans la barre latérale. » Chacune de ces parties peut échouer, et l'échec vous dit laquelle.
Comparez avec « vérifier que les filtres fonctionnent ». Même intention, mais pas d'état de départ, pas d'action précise, rien d'observable. Un agent chargé de la satisfaire fera quelque chose de raisonnable et annoncera un succès, et vous n'aurez rien appris. Les quinze secondes supplémentaires passées sur la première version font toute la différence.
Ensuite, cessez de décider quand les exécuter
Décrite ou codée, une vérification qui attend une intervention humaine est une vérification que l'on saute dans une semaine chargée.
Connectez le dépôt depuis le tableau de bord et les exécutions démarrent à partir du déploiement que vous produisez déjà, ou ajoutez plutôt une étape à votre propre workflow.
Ce que TestSprite fait d'une vérification décrite
Vous dites ce qui doit être vrai ; TestSprite détermine comment le vérifier et exécute la vérification sur votre application déployée. L'étape de traduction, celle qui n'a jamais été l'essentiel, disparaît.
Deux propriétés rendent le résultat durable. Les étapes sont enregistrées comme des intentions plutôt que comme des chemins dans le DOM : une refonte qui déplace un bouton ne casse donc pas la vérification. Et le résultat revient sous la forme d'une description de ce qui a été tenté, de ce qui s'est passé et de l'endroit où les deux ont divergé, ce qui permet à un agent de codage d'agir sur un échec sans qu'une personne ait à l'interpréter au préalable.
L'affinage se fait lui aussi en langage courant. Si une vérification est trop permissive, dites-le en une phrase plutôt que de modifier du code : c'est toute la raison d'être des vérifications décrites.
Le vibe testing est-il assez fiable pour un vrai produit ?
Pour une couverture comportementale des parcours, oui, à condition que chaque vérification nomme quelque chose de précis et que vous ayez confirmé qu'elle peut échouer. Pour des assertions sur une séquence exacte ou au niveau des composants, les tests écrits restent le meilleur instrument.
En quoi est-ce différent de l'enregistrement d'un parcours de clics ?
Un enregistrement capture un chemin et casse dès que le chemin change. Une vérification décrite capture une intention et survit au changement : c'est là l'essentiel de la différence en matière de maintenance.
Et si l'agent interprète ma description autrement ?
Lisez une fois les étapes générées avant de faire confiance à la vérification. Les erreurs d'interprétation y sautent aux yeux, alors qu'elles sont bien plus difficiles à repérer plus tard dans un résultat qui passe.
Puis-je affiner une vérification sans la réécrire ?
Oui. Ajustez-la en langage courant, de la même façon que vous l'avez décrite au départ.
Est-ce que cela remplace les tests unitaires ?
Non. Les tests unitaires sont plus rapides et plus efficaces sur la logique. Cette approche couvre la couche qu'ils ne voient pas : le fait que le produit assemblé se comporte correctement.
Décrivez quelque chose de précis, puis faites-le échouer une fois.
Le vibe testing supprime la traduction de l'intention en code de test, la partie qui n'a jamais été l'essentiel. Nommez un élément observable précis, confirmez que la vérification peut passer au rouge, et exécutez-la automatiquement plutôt que d'en décider à chaque fois.