Kent Beck connu pour avoir créé le concept de TDD est revenu il y a peu avec une nouvelle façon des tester : TCR (test && commit || revert). Je vais profiter de ce nouvel article pour faire un tour de ce concept de TCR (test && commit || revert).
Vous pouvez regarder la vidéo de La Minute Agile qui parle de ce sujet :
TCR (test && commit || revert)
Le TCR (test && commit || revert) propose un concept différent du TDD (test driven-development) que nous connaissons tous bien. N’hésitez pas d’ailleurs à visionner notre article sur le TDD si vous ne connaissez pas bien cette approche.
Article : Travailler en TDD (Test Driven Development)
Avec le TCR, les développeurs vont avancer doucement avec maitrise. Au moindre soucis rencontré, le code sera automatiquement remis à la dernière version fiable (« revert »).
Le code partagé sera donc toujours vert et fonctionnel pour l’ensemble de l’équipe.
TCR (test && commit || revert) risque de frustration ?
Cette approche est intéressante et mérite que nous nous y intéressons car elle est vraiment différente dans l’état d’esprit à avoir. Pourtant à première vue, nous pourrions nous dire : mais si tout le code disparait, les développeurs ne seront pas frustrés ?
Probablement les premières fois mais cela amènera les développeurs à faire attention et à être plus productif dans l’écriture de leur code ; voire, ils bénéficieront d’une suppression pour faire mieux la deuxième fois. N’est-ce pas une façon d’atteindre une excellence technique tant attendue par les approches agiles ?
TCR (test && commit || revert) : des développements en incrémental
Dans ce concept de TCR, les développement fonctionnent réellement en incrémental. Tu développes, tu fais valider et si le tout est bon, on développe en plus sur quelque chose de fiable.
L’ensemble des développeurs ne travailleront donc que sur du code fonctionnel et jamais sur des codes déjà en erreur.
Du coup le TCR n’empêche pas les développeurs de travailler plus vite mais leurs évite de publier des erreurs en cas de période de fatigue ou de grande pression.
TCR (test && commit || revert) versus TDD
Quand on regarde ce concept de plus prêt, on peut s’apercevoir que ces deux techniques relativement différentes ne sont pas forcément incompatibles. Pour rappel, la TDD propose un cycle de travail aux développeurs pour obtenir une qualité optimale de la mise en place des tests unitaires :
- Ecrire le test unitaire
- Lancer celui-ci et vérifier qu’il échoue (classe pas encore codée)
- Ecrire la classe à tester avec le minimum pour faire marcher le test
- Lancer le test et vérifier qu’il fonctionne
- Finir le code complet de la classe
- Vérifier que le test fonctionne toujours (non-régression)
Ne peut-on pas écrire ces tests en amont et vérifier qu’il échoue ? Il suffira de lancer que la commande « test » pour le vérifier en local sur son poste.
Bien que le concept de TCR soit très récent, il est possible de le coupler avec la TDD si vous pensez que ça peut-être intéressant. Rien ne vous l’interdit.
Les développeurs pourraient profiter du TCR pour les étapes de 3 à 6 tout en bénéficiant du bien fait de la TDD.
Conclusion TCR (test && commit || revert)
Ce concept de test très récent pourrait aider les équipes techniques à atteindre une meilleure excellence technique bien qu’elle ne couvrira pas tout à 100%.
N’hésitez pas à tester et à me faire vos retours sur cette technique en commentaire de ce blog.
Si je peux me permettre, Kent Beck n’a pas inventé le TDD, il l’a juste mis en avant en l’intégrant dans le concept XP.
Un article de 1968 en parle déjà:
http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF
Bien sûr que tu peux te permettre.
Saurais-tu me dire, où il y a la TDD ou le concept équivalent dans ton doc ? Je ne parle pas des tests unitaires mais vraiment de l’approche TDD.
Il n’y a pas réellement l’appellation de TDD, mais les prémisses d’une idée (celle de dire que les tests doivent se faire avant le codage) appelé TFD (Test First Design) pour ensuite évoluer vers du TDD (grâce à l’ajout du refactoring).
Dans ce document, c’est l’intervention de Perlis en page 32 (qui parle du document d’origine page 55) dans ces points 1 et 3.
Même chose ici, un article de 1957 (alors que Kent n’a introduit le TDD dans XP qu’en 2000):
http://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html
Le troisième argument (en milieu de doc) qui dit:
« Argument three is based on the constructive approach to the problem of program correctness. Today a usual technique is to make a program and then to test it. But: program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence. The only effective way to raise the confidence level of a program significantly is to give a convincing proof of its correctness. But one should not first make the program and then prove its correctness, because then the requirement of providing the proof would only increase the poor programmer’s burden. On the contrary: the programmer should let correctness proof and program grow hand in hand. »
Il y a ce très bel article de Xavier Pigeon qui explique bien mieux que moi d’où vient le TDD:
https://medium.com/@xavier.pigeon/du-test-first-design-au-test-driven-development-a07b05fdff6
En page 32, les remarques de Perlis sur la page 55 du rapport original (je pense qu’il est également de 1968), les points 1 et 3 remettent en cause le fait que les tests arrivent après le codage et propose de faire passer les tests avant, c’était les prémisse du TDD ou plus précisément du TFD (Test First Development) qui plus tard évoluera vers du TDD en ajoutant le refactoring.
Xavier Pigeon explique très bien ce passage dans son article:
https://medium.com/@xavier.pigeon/du-test-first-design-au-test-driven-development-a07b05fdff6
Même chose en 1957, (https://developsense.com/resources/1957-McCracken-ProgramCheckout.pdf) Mc Cracken propose un conception similaire en demandant à ce que les tests viennent avant le codage en posant la question du « A quoi bon faire un code puis tester si il est bon, autant ne pas perdre de temps et commencer des le début à le coder correctement, les tests seront utiliser comme fil conducteur (proof). D’ailleurs en passant, en page 163 il commence a évoquer le besoin d’un concept également similaire au pair programming pour améliorer la revue de code
Et j’ajoute également ce lien ou Kent Beck lui même répond a la question en disant qu’il redécouvre le TDD: Therefore I refer to my role as « rediscovering » TDD.
(https://www.quora.com/Why-does-Kent-Beck-refer-to-the-rediscovery-of-test-driven-development-Whats-the-history-of-test-driven-development-before-Kent-Becks-rediscovery)
merci beaucoup. Je vais alimenter les articles 🙂