il parle !
TDD ou pas TDD ? Comment savoir l'approche à privilégier ?
Comment décider s'il est judicieux de faire du TDD ou pas ? Mon bot Journey a maintenant la possibilité de parler en DM avec toi grâce à OpenAI, et voici comment j'ai procédé 👇
Tu vas y comprendre ma réflexion pour avancer étape par étape.
Tu n'oses pas écrire une seule ligne de code sans avoir écrit un test avant ?
Tu as peur de ne pas être un "vrai" professionnel si tu ne le fais pas ?
Ne t'inquiète pas, comme dans à peu près tout dans l'informatique (et la vie) il faut savoir être pragmatique.
Le TDD ne s'applique pas tout le temps, contrairement à ce que certains pourraient penser.
Les principes à partir desquels est né le TDD sont, eux, assez universels.
Voici comment les appliquer, sans parler de tests automatisés ;)
Mon bot Discord Journey peut maintenant communiquer grâce à OpenAI
Je vais te dire comment je m’y suis pris.
TDD ou pas TDD ?
Commençons par la partie DM.
Le plus important lorsque l’on développe, c’est la rapidité du feedback.
On cherche à réduire au maximum le temps entre une idée et sa mise entre les mains des utilisateurs.
Je voulais ici tester plusieurs choses :
Détecter un DM envoyé au Bot et répondre par DM
Envoyer en retour la réponse d’OpenAI
Afficher le feedback “journey-bot is typing...”
1ère question à se poser :
Est-ce que je sais exactement comment le faire ?
Réponse :
Je vois globalement comment le faire, sauf pour la partie DM
Ce que je sais faire :
Envoyer un message sur Discord
Utiliser l’API Assistant d’OpenAI
Ce que je ne sais pas faire :
Détecter un DM envoyé au bot
Répondre par DM à l’utilisateur Discord
2ème question :
Comment obtenir un feedback rapide sur ce que je ne sais pas faire pour vérifier que ça fonctionne ?
Réponse :
(Par exemple) : Afficher dans la console de mon serveur le message reçu en DM par l’utilisateur.
3ème question :
Quel est le type de logique qui entre en jeu ?
Réponse :
Logique d’intégration. Utilisation de l’API Discord, pas de logique algorithmique complexe
Décision :
Pas de TDD ici, car pas de logique unitaire à tester. Le feedback manuel est alors le plus pertinent et le plus rapide
Pas de TDD dans le code ne veut pas dire qu’on ne peut pas en appliquer les principes manuellement !
Procédons donc par baby-steps.
1ère étape : pouvoir afficher un message reçu dans la console.
Étape RED 🔴
Il se passe rien du tout dans le console. Normal ! Je n’ai encore rien implémenté !
Étape GREEN 🟢
Le message apparaît dans la console !
2ème étape : afficher uniquement les DM adressés au bot
Étape RED 🔴
Message envoyé en DM au bot :
Le nouveau message n’apparaît même pas alors qu’on aurait pu s’attendre à ce qu’il apparaisse ! Ça donne une piste sur le fait qu’il nous manque sûrement un intent !
Dans le TDD, à l’étape RED, il est important d’être dans une “bonne” étape RED.
C’est-à-dire que le test doit échouer de la façon dont on l’attend. Pour la “bonne raison”.
Ça peut être par exemple via le bon message d’erreur.
Dans notre cas, une “bonne” raison que le test échoue serait que le message s’affiche dans la console, indépendamment de s’il est reçu par DM ou par un autre canal.
Grâce à la doc, on apprend qu’il faut ajouter un intent, plus un “partials” :
On obtient maintenant une étape RED qui “fail” pour les bonnes raisons :
Les deux messages apparaissent. Le test sera “GREEN” lorsque uniquement le second s’affichera.
Étape GREEN 🟢
Bingo ! Seul le message envoyé en DM apparaît.
Grâce à une approche similaire au TDD, on a pu avancer par petites étapes vers notre objectif.
C’est l’essence même du développement : arriver à diviser un gros problème en plus petits problèmes.
Le cas d’usage est ici relativement simple mais démontre un état d’esprit important à adopter.
Dès lors, le “vrai” TDD devient naturel lorsque la meilleure façon d’obtenir un feedback est un feedback instantané grâce aux tests unitaires !
Happy Coding !
Pierre.
PS : Si tu n’est pas encore inscrit.e aux Cursus Craft Academy, en venant de la newsletter tu bénéficies de 40% de réduction sur tous les cursus :)