TDD (Test-Driven Development) – Mon parcours personnel

Qu’est-ce que le TDD ? TDD est l’abréviation de “Test-Driven Development” (développement piloté par les tests) et c’est un logiciel
Le processus de développement qui a été crédité au Kent
Beck. L’idée consiste à rédiger des tests unitaires pour
votre programme, en les faisant échouer, puis en introduisant la quantité minimale de code que
est suffisant pour réussir le test, alors vous continuez à écrire d’autres tests selon
à vos besoins. Grâce aux tests mis en place, tout changement que vous effectuez sur
votre code principal (appelons-le désormais code de production) peut être comparé à
Ces tests et leur exécution à chaque nouveau changement peuvent être un moyen d’accélérer
comme alternative au démarrage de votre application (quelle qu’elle soit), géré par
chaque scénario et vérifier si les choses fonctionnent comme prévu.


Approche traditionnelle


Approche DRT

Mon parcours

Le TDD (Test-Driven Development) est l’une des nombreuses techniques de développement de logiciels
et cet article vise à partager mon expérience personnelle avec elle. J’espère que je pourrai
de clarifier mes réflexions sur quand je pense qu’il peut aider et quand je crois que nous
devrait prendre du recul. Je dois dire que J’ai trouvé le TDD assez difficile et
résumé au début
. Il y aura toujours un espace de discussion et c’est pourquoi
d’autres processus tels que la programmation par paires et l’examen des codes sont extrêmement
complémentaire de ce que je considère comme des processus de développement de logiciels sains. Laissez-moi
vous donner un certain contexte avant de commencer, afin que vous puissiez mieux comprendre où je
est venu de.

J’ai commencé à lire des articles sur les troubles de la personnalité sur Internet et sur ce qui m’a le plus aidé dans ma
Les premiers pas ont été les articles du Caelum
site web. J’ai trouvé de très bons exemples de la façon de procéder à l’époque grâce à leur
et j’ai trouvé des livres qui m’ont conduit à
les définitions formelles rédigées par Kent Beck. Puis j’ai rejoint
ThoughtWorks en 2011 et je crois que c’était là
un tournant pour moi. ThoughtWorks est célèbre pour son esprit révolutionnaire
(recherchez le manifeste agile), la Tech
Publications sur les radars et pour se soucier
la qualité du code. Cependant, la raison pour laquelle je pense que travailler là-bas était si important était
grâce aux personnes avec lesquelles j’ai eu la chance de travailler à l’époque. Ils ont vraiment
m’a encouragé à remettre en question l’état actuel du code et la façon dont il pourrait être
améliorée. Nous avions également une forte culture de programmation en binôme qui, combinée à
En écrivant des tests, la remise en question de la maintenabilité du code est devenue assez naturelle.

Pourquoi est-ce que je crois que le TDD est important ?

Le développement piloté par les tests permet le remaniement.

Comme je l’ai mentionné plus haut, le fait d’avoir des tests qui exercent l’intention de votre code (fonction
ou méthode) permet de remanier le code avec une plus grande confiance. Vous pouvez
déplacer des choses, vous pouvez renommer les choses qui expriment mieux ce que vous essayez
pour faire, vous pouvez ajouter un argument à une fonction ou vous pouvez les supprimer tous. Si
après tout cela, vous faites vos tests et ils sont réussis, il y a de fortes chances que vous ayez fait
tout va bien ! L’inverse est également vrai. Si vous changez les choses et qu’après
en effectuant les tests que certains d’entre eux échouent, cela pourrait être un signe que vous avez fait
quelque chose qui ne va pas et qui doit être corrigé. En remaniant le code, si vous remarquez
qu’un seul changement affecte plusieurs tests, cela pourrait être un signe que l
le couplage entre les composants est élevé ou l’ampleur du changement/réacteur est importante.

Avec le temps, J’ai appris que la DDT ne consiste pas nécessairement à tester d’abord. Le site
processus consistant à passer des tests d’abord, les voir échouer puis les faire passer pour être
La capacité à remanier les données aide vraiment, mais pour moi, le facteur clé a été de laisser les tests conduire
comment je pense pour que l’ampleur de mes changements puisse être exprimée dans les tests. Je pourrais
veulent remanier quelque chose, mais si mes scénarios sont assez petits, je peux reporter
cette décision pour plus tard.

Le développement basé sur les tests favorise la conception

Le TDD consiste à laisser vos tests vous guider sur le problème que vous devez
résoudre. Il est assez courant d’utiliser ici la terminologie “baby steps”. Fondamentalement,
vous commencerez par des scénarios vraiment petits et basiques (pour une entrée donnée, je
attendre ce résultat). Dans cette optique, la conception de votre code doit être suffisamment simple
pour satisfaire aux exigences. Un autre aspect qui peut contribuer à une meilleure conception
est que votre test est le premier consommateur de votre code. C’est là que vous appellerez le
fonction que vous avez soigneusement nommée et que vous avez minutieusement ajouté certains arguments et vous
verra si cela exprime vraiment ce que vous voulez faire. Vous pouvez demander : “Dois-je
passer vraiment 4 arguments ici ?” “Est-ce que ce nom est bon ?” “Ce n’est pas trop compliqué à
de mettre en place l’état initial pour tester seulement si cela fait ce qu’il faut”. Si
la réponse à cette question ne semble pas tout à fait correcte, vous pouvez utiliser ceci
possibilité de changer votre code et de revoir vos tests unitaires et d’imaginer :
“comment quelqu’un appellera ce code dans la vie réelle ? Est-il facile à lire ?”.

Parfois, il n’est pas possible de dire : “Pour une entrée donnée, j’attends cette sortie”. Vous pourriez
font valoir que ce n’est pas aussi simple que cela, car il n’est parfois pas facile de structurer les apports
et les résultats attendus. Toutefois, le fait que cela ne soit pas toujours possible
ne change pas le fait que vous pouvez toujours y réfléchir et en faire un
l’exercice. Relevez souvent le défi et voyez si c’est vraiment le cas. Si ce n’est pas le cas,
essayez de décomposer votre code en composants plus petits et posez ensuite la question suivante
à nouveau.

Une bonne conception de code est assez subjective !

OUI ! C’est cela ! Si je fais le codage tout seul, je suis presque sûr que je le comprendrai
toutes et chaque décision aura un sens jusqu’à ce que je doive l’expliquer à quelqu’un.
C’est ainsi que la programmation en binôme et/ou la révision du code devient ici cruciale. Le processus
de faire du TDD fait aussi évoluer l’empathie. J’ai tendance à penser que nous devons résoudre certains
problèmes tout de suite, mais souvent, lorsque je partage mes pensées avec quelqu’un, je me rends
que je pense trop loin devant moi. De telles conversations peuvent vous aider à éviter
suringénierie et prendre des décisions prématurément. Comme nous le savons maintenant, nos tests sont
les premiers consommateurs de notre code, alors appuyez-vous sur cela et discutez avec vos pairs
si c’est vraiment un bon design. Voici quelques questions que j’essaie souvent
de me demander :

TDD ne signifie pas code sans bogues !

J’ai entendu un argument avant de dire que si vous faites un TDD, votre code
ne devrait pas avoir de mouchards. Je crois que c’est une déclaration audacieuse. Bien sûr, mon
peut avoir des bogues. Le développement piloté par les tests est une technique qui nécessite
la discipline et l’expérience. Si je ne suis pas les étapes, par exemple, si je n’ai jamais
voir mes tests échouer, je peux tomber dans le piège des faux positifs. Il est crucial de
Passez un test, voyez-le échouer, puis faites-le passer ! Les tests doivent également être fiables.
Le fait que nos tests soient également faciles à utiliser fait partie de la bonne conception que j’ai mentionnée plus haut
lire et maintenir. Ils doivent être prévisibles et propres. S’il y a trop de
des dépendances ou des configurations, cela pourrait être le signe que mon code est trop couplé,
Il sera donc difficile à maintenir et des faux positifs pourront être introduits.
En outre, à ce stade, on peut se demander si le fait d’avoir des tests apporte vraiment une valeur ajoutée
compte tenu de l’ampleur des préparatifs qu’elle pourrait nécessiter si vous en arriviez là.

Il y a un autre aspect à cela, qui est : nous pouvons encore écrire des tonnes de tests unitaires
en suivant toutes les règles, mais avec de fausses hypothèses. Si nous ne comprenons pas
le problème que nous essayons de résoudre, nous finirons par avoir des tests qui
exercer quelque chose qui n’a pas de sens avec des tests réussis.

Outillage

Dans les sections précédentes, j’ai décrit les techniques, les croyances et la discipline. À l’adresse
Il faut qu’il soit agréable et qu’il colle, nous devons avoir un bon outillage. Les tests doivent être
rapide à courir. Il devrait être plus rapide d’exécuter un test que d’ouvrir l’application (c’est-à-dire
navigateur ou appareil mobile) moi-même et de la tester. Lors du codage, il devrait être
rapide pour déclencher les tests également. De nos jours, la plupart des langages de programmation”.
les écosystèmes contiennent un outil qui surveille votre code et chaque fois que vous sauvegardez un
les tests relatifs à ce dossier seront effectués. C’est le point idéal, dans mon
opinion.

Réflexions finales et quand faire une ATS n’aide pas

Je pense que le développement par les tests n’est pas utile quand nous ne sommes pas tout à fait
certain de ce qu’il faut faire et de ce à quoi il faut s’attendre. Parfois, vous n’êtes pas
vous connaissez la langue, le cadre ou la plate-forme et vous pourriez avoir besoin d’un peu de temps
de jouer avec les API disponibles et de voir ce qui est possible et ce qui peut
être une contrainte.

Comme le résultat escompté peut être inconnu, le fait de faire guider le développement par des tests
peut être extrêmement difficile, car la DTT consiste à définir les attentes et
en trouvant comment les rencontrer. Donc, ce qui fonctionne bien pour moi, c’est de faire vite
expériences, écrire du code sans aucun test, voir ce qui peut être fait, explorer
les limites de l’outil/plate-forme/API, puis redémarrer avec l’esprit TDD en utilisant le
des expériences comme référence/documentation. Après cela, je peux sans risque jeter le
expérimenter et continuer avec le nouveau code.

Bien sûr, cela ne fonctionne peut-être pas pour tout le monde, mais comme je l’ai mentionné à plusieurs reprises, cela
est une question d’exercice. Si vous essayez de faire cela, vous pourriez apprendre une chose ou deux
et la prochaine fois, vous serez plus performant. Tout ce que je veux, c’est un bref retour d’information et le
capacité d’itération sur ma compréhension du problème en question souvent.

Références