J'ai récemment donné une conférence sur le débogage pour la communauté Java de Londres. Au cours de la partie questions-réponses de la conférence, quelqu'un m'a posé des questions sur mon approche du développement piloté par les tests. Dans le passé, je regardais cette pratique sous un jour plus positif. Rédaction de nombreux tests. Comment cela peut-il être mauvais ?  Mais au fil du temps, je le vois sous un jour différent.  Je le vois comme un outil très limité qui a des cas d'utilisation très spécifiques. Cela ne correspond pas au type de projets que je construis et entrave souvent les processus fluides qu'il est censé promouvoir. Mais revenons en arrière une seconde. J'ai beaucoup aimé   qui sépare les types et les problèmes en TDD. Mais simplifions un peu, précisons que chaque PR doit avoir une bonne couverture. Ce n'est pas TDD. C'est juste une bonne programmation. ce post  TDD est plus que cela. Dans celui-ci, nous devons définir les contraintes puis résoudre le problème. Cette approche est-elle supérieure à la résolution du problème puis à la vérification que les contraintes sont correctes ? C'est le principe de base de TDD par rapport à la simple écriture d'une bonne couverture de test.  Le bon  TDD est une approche intéressante. C'est particulièrement utile lorsque vous travaillez avec des langages faiblement typés. Dans ces situations, TDD est merveilleux car il remplit le rôle d'un compilateur strict et d'un linter.  Il y a d'autres cas où cela a du sens. Lorsque nous construisons un système qui a des entrées et des sorties très bien définies. J'ai rencontré beaucoup de ces cas lors de la création de cours et de matériel. Lorsque vous travaillez sur des données du monde réel, cela se produit parfois lorsque nous avons un middleware qui traite les données et les sort dans un format prédéfini.  L'idée est de construire l'équation avec les variables cachées au milieu. Ensuite, le codage devient le remplissage de l'équation. C'est très pratique dans des cas comme ça. Le codage devient le remplissage des blancs.  Le mauvais  “Test Driven Development   Comptabilité en partie double. Même disciplines. Même raisonnement. Même résultat. – Oncle Bob Martin IS  Je dirais que les tests sont un peu comme une comptabilité en partie double. Oui. On devrait faire des tests. La question est de savoir si nous devons construire notre code en fonction de nos tests ou vice versa ? Ici, la réponse n'est pas si simple.  Si nous avons un système préexistant avec des tests, alors TDD prend tout son sens dans le monde. Mais tester un système qui n'a pas encore été construit. Il y a des cas où cela a du sens, mais pas aussi souvent qu'on pourrait le penser.  La grande revendication de TDD est « sa conception ». Les tests sont effectivement la conception du système, et nous mettons ensuite en œuvre cette conception. Le problème avec cela est que nous ne pouvons pas non plus déboguer une conception. Dans le passé, j'ai travaillé sur un projet pour une grande entreprise japonaise. Cette société possédait l'un des ensembles les plus importants et les plus détaillés de manuels de conception d'annexes. Sur la base de ces spécifications de conception, l'entreprise a construit des milliers de tests. Nous étions censés passer une énorme quantité de tests avec notre système. Notez que la plupart n'étaient même pas automatiques.  Les tests avaient des bugs. Il y avait de nombreuses implémentations concurrentes mais aucune d'entre elles n'a trouvé les bogues dans les tests. Pourquoi? Ils utilisaient tous le même code source d'implémentation de référence. Nous avons été la première équipe à sauter cela et à faire une implémentation en salle blanche. Il a perpétué ces bogues dans le code, dont certains étaient de graves bogues de performances qui affectaient toutes les versions précédentes.  Mais le vrai problème était la lenteur des progrès. L'entreprise ne pouvait pas avancer rapidement. Les partisans du TDD seront prompts à commenter qu'un projet TDD est plus facile à refactoriser puisque les tests nous donnent la garantie que nous n'aurons pas de régressions. Mais cela s'applique aux projets avec des tests effectués après coup.  Le pire  TDD se concentre fortement sur les tests unitaires rapides. Il n'est pas pratique d'exécuter des tests d'intégration lents ou des tests de longue durée qui peuvent s'exécuter pendant la nuit sur un système TDD. Comment vérifier l'échelle et l'intégration dans un système majeur ?  Dans un monde idéal, tout se mettra en place comme des legos. Je ne vis pas dans un tel monde, les tests d'intégration échouent mal. Ce sont les pires échecs avec les bogues les plus difficiles à suivre. Je préférerais de beaucoup avoir un échec dans les tests unitaires, c'est pourquoi je les ai. Ils sont faciles à réparer. Mais même avec une couverture parfaite, ils ne testent pas correctement l'interconnexion. Nous avons besoin de tests d'intégration et ils trouvent les bogues les plus terribles.  En conséquence, TDD met trop l'accent sur les tests unitaires « agréables à avoir », au détriment des tests d'intégration essentiels. Oui, vous devriez avoir les deux. Mais je dois avoir les tests d'intégration. Ceux-ci ne s'intègrent pas aussi clairement dans le processus TDD.  Tests axés sur la droite  J'écris les tests de la manière que je choisis au cas par cas. Si j'ai un cas où il est naturel de tester à l'avance, je l'utiliserai. Mais dans la plupart des cas, écrire le code en premier me semble plus naturel. Passer en revue les chiffres de couverture est très utile lors de la rédaction de tests et c'est quelque chose que je fais après coup.  Comme je l'ai mentionné précédemment, je vérifie uniquement la couverture des tests d'intégration. J'aime les tests unitaires et le suivi de la couverture car je veux une bonne couverture là aussi. Mais pour la qualité, seuls les tests d'intégration comptent. Un PR a besoin de tests unitaires, peu m'importe si nous les avons écrits avant l'implémentation. Nous devrions juger les résultats.  Mauvaise automatisation  Lorsque   construisait ses usines de modèle 3, il est entré dans l'enfer de la production. La source des problèmes était leur tentative de tout automatiser. Le   s'applique parfaitement à l'automatisation. Certaines choses sont tout simplement très résistantes à l'automatisation et rendent l'ensemble du processus bien pire. Tesla principe de Pareto  Un point où cela échoue vraiment est dans les tests d'interface utilisateur. Des solutions telles que Selenium, etc. ont fait d'énormes progrès dans les tests des frontaux Web. Pourtant, la complexité est énorme et les tests sont très fragiles. Nous nous retrouvons avec des tests difficiles à maintenir. Pire encore, nous trouvons l'interface utilisateur plus difficile à refactoriser car nous ne voulons pas réécrire les tests.  Nous pouvons probablement croiser 80% des fonctionnalités testées, mais il y a un point de rendements décroissants pour l'automatisation. Dans ces environnements, TDD est problématique. La fonctionnalité est simple mais construire les tests devient intenable.  Pour terminer  Je ne suis pas contre le TDD mais je ne le recommande pas et effectivement je ne l'utilise pas. Quand il est logique de commencer par un test, je peux le faire, mais ce n'est pas vraiment TDD. Je juge le code en fonction des résultats. TDD peut fournir d'excellents résultats, mais il met souvent trop l'accent sur les tests unitaires. Les tests d'intégration sont plus importants pour la qualité à long terme.  L'automatisation est excellente. Jusqu'à ce que ça s'arrête. Il y a un moment où les tests automatisés n'ont plus aucun sens. Cela nous ferait économiser beaucoup de temps et d'efforts pour accepter cela et concentrer nos efforts dans une direction productive.  Cela vient de mon parti pris en tant que développeur Java qui aime les langages stricts et sécurisés. Des langages tels que JavaScript et Python peuvent bénéficier d'un plus grand volume de tests en raison de leur flexibilité. Par conséquent, TDD a plus de sens dans ces environnements.  En résumé, les tests sont bons. TDD ne fait cependant pas de meilleurs tests. C'est une approche intéressante si elle fonctionne pour vous. Dans certains cas, c'est énorme. Mais l'idée que TDD est essentiel ou même qu'il améliorera considérablement le code résultant, n'a pas de sens.  Également publié  ici.

Shai is a Developer Advocate at Lightrun, where he's busy explaining why hotfixing just to add a log line needs to be a thing of the past. He is also a JavaOne rockstar that has been developing software professionally for ~30 years, a published author, an open-source hacker (founder and long-time maintainer of Codename One) , an experienced Java trainer and a public speaker. When he's not in front of his machine you can find him making food for his two kids or doing Yoga with his wife (well, at least attempting to).

2021 - HackerNoon Contributor of the Year - DEBUGGING

2022 - HackerNoon Contributor of the Year - Coding Skills

2022 - HackerNoon Contributor of the Year - Debugging

2022 - HackerNoon Contributor of the Year - Java

2022 - HackerNoon Contributor of the Year - Monitoring

2022 - HackerNoon Contributor of the Year - Software Testing

Debug Agent

Buy My Book

Learn on my YouTube Channel

Read My Stories

Newsletter

Follow me on Twitter

Author/DevRel/Entrepreneur/Hacker

Cet audio est produit dans la langue originale de l'histoire !

Trop long; Pour lire

Pourquoi je ne pense pas que le TDD soit essentiel

Pourquoi je ne pense pas que le TDD soit essentiel

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Guide de l'architecte pour créer une architecture de référence pour un datalake IA/ML

Libérer la puissance de l’IA. Une revue systématique des techniques de pointe : résumé et introduction

Le modèle Bitcoin UTXO, alimentant un écosystème unique

Des forums aux flux : comment les algorithmes des réseaux sociaux façonnent l'interaction numérique

Guide de l'architecte pour créer une architecture de référence pour un datalake IA/ML

Libérer la puissance de l’IA. Une revue systématique des techniques de pointe : résumé et introduction

Le modèle Bitcoin UTXO, alimentant un écosystème unique

Des forums aux flux : comment les algorithmes des réseaux sociaux façonnent l'interaction numérique

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps