On s’occupe du fastidieux, pour que vous puissiez vous concentrer sur le plaisir
Si vous êtes ici à lire ces lignes, il y a de bonnes chances que vous soyez comme moi. Soyons honnêtes deux secondes : on déteste s’occuper du code de test. En tant que développeurs et développeuses, ce qu’on veut, c’est coder des fonctionnalités. On veut créer des logiciels qu’on peut fièrement pousser jusqu’aux limites du possible, et même au-delà. Parce qu’au fond, nous sommes des artisanes et des artisans. Bien sûr, on veut que notre code fonctionne comme prévu, alors on fait tout ce qui est en notre pouvoir pour qu’il soit testé.
Mais on ne veut pas y passer 80 % de notre temps de travail!
Tout le monde déteste quand le code a des bogues. C’est un combat sans fin. Mais je ne suis pas certain qu’on utilise les bonnes armes.
Pour régler le problème, on l’a d’abord attaqué avec l’outil qu’on connaît : le code. On a créé des tests automatisés. Au début, tout allait bien, puis très vite, l’enfer a commencé. Parce que le code de test n’est pas aussi stimulant que le code de fonctionnalités. Il ne le sera jamais.
Alors on vous a convaincus que le TDD était la solution. Pour nous forcer à écrire ce maudit code de tests automatisés. On nous a incités à courir après ce chiffre magique de couverture. Et on nous a aussi punis quand on n’atteignait pas les cibles fixées. Le tout enrobé de stratégies corporatives plus ou moins subtilement passives-agressives. On a serré les dents, en se convainquant que c’était la meilleure solution possible.
Puis l’IA est arrivée. Et devinez quoi? Encore plus de code de test!
Ça devrait régler le problème, puisqu’on n’a plus besoin d’écrire le code de test, non?
Non?
Oui, bien sûr. Alors maintenant, vous avez des tonnes de code de test généré.
Mais devinez quoi : qui va le déboguer, maintenant? Le refactoriser? Le maintenir? L’optimiser?
Vous connaissez la réponse. Ce ne sera pas l’IA. L’IA ne fait que cracher du code de test gonflé qui ressemble à du code de test. Elle n’a aucune idée de pourquoi il est mauvais, ni de ce qu’il teste. Et vous non plus, parce que ce n’est pas vous qui l’avez écrit!
Le code sera toujours un passif. Le code de test n’échappe pas magiquement à cette réalité.
Il faut donc réduire le code, pas en générer davantage. Les tests devraient se rapprocher le plus possible d’un processus entièrement automatisé, et ils doivent être jetables. Ils doivent être générés à partir des intrants d’utilisateurs experts, pour garantir leur pertinence.
Et plus aucun dev ne devrait jamais avoir à se battre avec du code de test.
C’est cette vision que Yesbot veut propulser.
Yesbot ne cherche à remplacer personne, parce qu’il sait que la compréhension et l’expertise humaines d’un système sont irremplaçables.
Yesbot est là comme un super-outil pour générer facilement des tests, et libérer les équipes de développement pour qu’elles se concentrent sur ce qu’elles aiment : bâtir des logiciels extraordinaires!
Merci si vous avez lu jusqu’ici. Peut-être aimeriez-vous maintenant voir quelques arguments qui pourraient convaincre votre équipe.
