Transcription pour Epsiode 23: Leçons sur les tests et le TDD de Kent Beck

By | octobre 26, 2019

Formation gratuite Python

Ceci est la transcription de Test & Code, épisode 23: Leçons sur les tests et le TDD de Kent Beck

[music] Bienvenue dans Test and Code, un podcast sur le développement et les tests de logiciels. Le profil Twitter de Kent Beck indique «programmeur, auteur, père, mari et éleveur de chèvres», mais je le connais mieux pour ses travaux sur la programmation extrême, la programmation test-test et le développement piloté par les tests. C'est le bon. Si vous connaissez TDD, c'est à cause de Kent Beck. Je suis tombé sur ses écrits lorsque j’étudiais la programmation extrême au début des années 2000. Bien que je ne partage pas tous les points de vue qu’il a exprimés sur sa longue et prolifique carrière, je le respecte comme l’une des meilleures sources d’information sur le développement de logiciels, les pratiques d’ingénierie et les tests de logiciels. Parallèlement à Test First Programming et Test Driven Development, Kent a lancé un framework de test automatisé qui s'est transformé en JUnit. JUnit, ainsi que son modèle de configuration et de démontage, l’enveloppement de fonctions de test, ainsi que les frameworks de test pilotés par classe de tests de base, sont devenus ce que nous connaissons maintenant comme des frameworks de style xUnit, qui incluent le plus inconditionnel de Python. Il a parlé de cette histoire et de beaucoup d'autres choses sur l'épisode 122 de Software Engineering Radio. L'épisode s'intitule "L'histoire de JUnit et l'avenir des tests avec Kent Beck" et date du 26 septembre 2010. Je mettrai un lien dans les notes de l'émission. Je vous exhorte à le télécharger et à écouter le tout. C'est une excellente interview, toujours pertinente et applicable aux tests dans toutes les langues, y compris Python. Cependant, je sais que beaucoup d’entre vous ne vont pas l’écouter, et il ya quelques passages de l’interview que je veux vraiment partager avec vous. Alors voici ce que j’ai fait. J'ai recherché les bonnes personnes pour demander la permission de sortir des extraits de cette interview et de les diffuser sur ce podcast. Ils ont dit que c'était OK. En fait, depuis que SE Radio fait partie de l'IEEE, ma demande a fini par être adressée à quelqu'un de l'IEEE Computer Society. Ils ont dit oui, ce qui est cool, alors nous voici. Oh oui, j'ai demandé à Kent via Twitter si je pouvais le présenter comme un éleveur de chèvres de l'Oregon. Sa réponse: "ça va". Nous y voilà donc, quelques bouts de logiciel testant la sagesse d'un éleveur de chèvres en Oregon.

[2:22] Le premier clip concerne la lisibilité de vos tests et leur récit.

«Je cherche toujours une sorte d'expression déclarative dans mes tests. Vous devriez être capable de lire un test et cela raconte une histoire. C'est-à-dire que quelqu'un qui vient lire plus tard devrait être capable de comprendre quelque chose d'important sur le programme. ”

Parfois, les bonnes pratiques de programmation normales ne s’appliquent pas aux tests de logiciels. Un exemple est DRY. DRY signifie "ne vous répétez pas" et beaucoup de gens pensent que si vous avez des morceaux de code répétés, vous devriez les mettre dans une fonction et appeler cette fonction à la place. Les tests logiciels ont naturellement un code similaire à d’autres tests et il est tentant de placer les lignes communes dans une fonction distincte. Voici Kent sur le sujet:

"DRY en particulier, je ne m'inscris pas pour le code de test, car je veux que mes tests se lisent comme une histoire."

[3:21] Kent a également évoqué l’idée que les tests devraient faire progresser vos connaissances du logiciel testé. Un test qui échoue devrait légitimement vous informer de nouvelles informations sur le problème rencontré dans votre logiciel. Il met également en garde de ne pas avoir plusieurs tests qui vous disent la même chose à propos de votre logiciel.

«En médecine, ils appellent cela un diagnostic différentiel, où ils disent que je vais commander ce test, et sur la base des résultats, tu sauras quoi que ce soit, test sanguin, je pourrai exclure un groupe de choses et de confirmer d'autres choses. Donc, chaque test devrait avoir ce genre de, peut-être est-ce une question de théorie de l'information, devrait être capable de différencier les bons programmes des mauvais programmes. Si vous avez un test et que cela ne fait rien pour améliorer votre compréhension des bons programmes et des mauvais programmes, il s’agit probablement d’un test inutile. Mais si vous prenez l’espace de tous les programmes possibles pour résoudre votre problème, vous savez, la quasi-totalité d’entre eux ne le seront pas, et quelques-uns le feront. Un test devrait couper une grande partie de cet espace et dire non, tout programme qui ne satisfait pas à ce test ne va certainement pas résoudre le vrai problème. Donc, il y a une partie de cela. Et puis, il y a un sentiment de redondance. Si vous avez un tas de tests qui vous disent exactement la même chose, alors, je chercherais lequel de ceux-ci ajoute le moins de valeur et les supprime. Mais ils doivent vraiment couvrir exactement les mêmes cas. "

[5:06] Ce clip est l'un de mes favoris. Vous voyez, quand j'ai appris la première fois sur Test First Programming et Test Driven Development, j'ai compris que c'était utile au niveau de l'API utilisateur, avec une idée des unités fonctionnelles. J'ai également trouvé très utile d'écrire des tests au niveau des interfaces de couche, en particulier lorsque je travaillais sur une couche plus proche du matériel et je voulais tester, à partir de mon niveau, une fonctionnalité prête dans le matériel mais ne comportant pas de couches supérieures. prêt pour le moment et aucune API disponible pour le moment. Je pense que le niveau, l’interface où vous appliquez vos tests, est une décision pragmatique basée sur les circonstances dans lesquelles vous vous trouvez. Mais ce n’est pas ainsi que beaucoup de gens l’ont vue. Un grand nombre de partisans du TDD, autres que Kent, sont venus et ont poussé des tests unitaires isolés, et ont essayé de faire passer les tests de bout en bout et les tests système par-dessus la clôture aux équipes d'assurance qualité. Je suis donc très heureux d’entendre Kent parler de tests à différents niveaux ou, comme il dit, de différentes échelles.

«Quelque chose que je n’ai pas communiqué très efficacement lors de mes premières discussions sur le TDD est l’importance des tests à différentes échelles. Donc, TDD n'est pas une philosophie de tests unitaires. J'écris des tests à n'importe quelle échelle dont j'ai besoin pour m'aider à progresser. Donc, parfois, c’est ce que d’autres appellent un test fonctionnel. Ainsi, par exemple, quarante pour cent des tests JUnit fonctionnent via l'API publique. Soixante pour cent d’entre eux travaillent sur des objets de niveau inférieur. L'API publique est assez bonne pour les tests, probablement parce que nous avons écrit beaucoup de tests, donc je ne sais pas si ces proportions sont – je ne veux pas prétendre que ces proportions sont plus qu'un point de données, comme si vous deviez avoir 40-60, si vous avez 10-90 ou 90-10, je ne sais pas vraiment, mais juste cette idée de déplacer – Une partie de la compétence de TDD consiste à apprendre à passer d’une échelle à l’autre. Alors j’écris un test que mon client dit «oh, ce scénario devrait donner cinq». Donc, vous écrivez un test qui dit que ce scénario devrait aboutir à un 5, puis que vous êtes plongé au fond de l'intestin de votre programme et que vous pensez, oh, je vois, eh bien cet objet quand on lui donne cinq et sept devrait retourne les cinq. C’est un bon endroit pour passer un test, car c’est un autre élément de l’histoire à raconter. Mais, vous savez, s’agit-il d’un développement fondé sur des tests d’acceptation ou bien de BDD? Je pense qu'ériger des murs rigides entre les styles est en fait une erreur, comme les balances, en tant que programmeur, je veux comprendre toutes ces échelles. Les tests m'aident à comprendre, alors j'écris des tests à toutes ces échelles. ”

[8:18] Disons que vous avez des tests en place qui vous donnent des informations sur votre système et racontent bien une histoire. Les tests sont des logiciels et doivent être maintenus. Votre système ne devrait pas comporter de tests difficiles à comprendre car, à un moment donné, ce test échouera et quelqu'un devra comprendre pourquoi il échoue. C’est là que la lisibilité et la valeur sont très importantes. J'en ai marre que les gens disent que les tests de bout en bout sont fragiles, ce qui signifie qu'ils se cassent tout le temps. Écoutez, si vous écrivez un test à l’aide de votre API, même si c’est une longue histoire, c’est un peu ce que vos clients vont faire avec votre logiciel. En cas de panne ou d’échec, c’est le code de vos clients qui le sera aussi. C’est sérieux! Si c’est vraiment un problème de test, c’est bizarre, mais je dois dire que les tests de bout en bout ne doivent pas nécessairement être longs. Les tests fonctionnels ciblés peuvent être courts. Mais parfois, il doit être long pour correspondre à un modèle d'utilisation réel du client. Ainsi soit-il, c’est long. Mais si cela échoue, prenez-le aussi au sérieux qu'un rapport d'anomalie client. Voici Kent sur le sujet.

«Je me rends toujours dans les lieux et les gens disent:« ah ouais, on a fait un tas de tests, mais ensuite les tests ont cessé de fonctionner, alors on les a jeté », ce qui me semble bizarre. Je veux dire, comme, Aristote serait choqué. La logique ne s’ajoute pas. Ce test a indiqué que si le test est en cours, mon programme est en cours d’exécution et que le test ne s’exécute pas, alors mon programme ne fonctionne pas. Et le test s'arrête, et votre prochaine action consiste à supprimer le test, ou simplement arrêter de l'exécuter ou ignorer le rapport de test que vous obtenez. Wow, cela signifie que votre programme ne fonctionne pas. Mais de toute façon, je veux dire, il y a beaucoup de pressions sur les personnes autres que le lancement de votre programme. Je suppose que c’est la conclusion que je peux tirer de cela, mais c’est un peu dommage, je pense. Les programmeurs pourraient avoir plus de valeur en faisant confiance aux tests et en leur accordant une plus grande attention. Mais moi, vous savez, beaucoup de choses se passent dans le développement de logiciels que le codage. "

[10:32] Jusqu'ici, je suis d'accord avec tout ce que j'ai joué. J'ai pensé qu'il serait peut-être juste de jouer un clip avec lequel je ne suis pas d'accord. Je vais juste y jouer et en discuter après.

«Je pense que cela vaut la peine d’être dogmatique comme outil d’apprentissage, non? Et si je disais juste que je vais toujours écrire des tests pour tout. Et puis vous découvrez, oh, je suis content d’avoir fait cela. Ici, je suis désolé de l’avoir fait. Donc, je ne le ferai pas – quelles sont les similitudes dans les expériences où je souhaitais ne pas avoir passé de tests, quelles étaient les similitudes dans les expériences dans lesquelles je suis content d'avoir écrit les tests, puis laissez-moi déduire utilisez-le pour informer mon comportement à l'avenir. "

Il dit qu'il est acceptable d'enseigner le TDD de manière dogmatique et que les gens apprendront avec ces roues d'entraînement et que, lorsqu'ils deviendront plus vieux que le dogmatisme, ils laisseront leur bon sens dicter à quel point ils doivent tester et ce qui doit être testé. et ce qui ne l'est pas. Mais, je pense que l'histoire nous dit que vous ne pouvez pas toujours compter sur le bon sens des gens pour intervenir, et il y a beaucoup de gens qui disent des choses comme «tu ne fais pas vraiment le TDD», «ce n'est pas un test unitaire parce que vous n'utilisez pas de simulacres »,« les tests unitaires ne doivent toucher ni la base de données ni le système de fichiers »,« ce n'est pas vraiment Scrum, c'est ScrumBut », et ce genre de choses. En tout cas, j'en ai marre du dogmatisme et de l'excuse que les gens sont assez intelligents pour savoir que nous ne voulons pas vraiment tout tester. Nous devrions enseigner aux gens ce qu’ils doivent vraiment faire, et non une version idéalisée qu’ils sont censés savoir changer pour pouvoir s’y prendre.

[12:07] Quoi qu’il en soit, nous sommes six ans plus tard et j’aimerais bien avoir une entrevue avec Kent Beck et l’interroger à propos de ces clips et de l’élevage de chèvres. Et je suis vraiment curieux de savoir s’il a découvert les IPA et le pinot noir, comme la moitié du reste de l’Oregon. C’est irréel, surtout en été, vous seriez surpris de voir à quel point il est difficile de trouver une bière qui ne soit pas une IPA, ni l’une de ses variantes. Alors, qu'avons-nous couvert?

  1. Vos tests devraient raconter une histoire.
  2. Méfiez-vous des pratiques de DRY, d'héritage et de développement de logiciels qui pourraient gêner la compréhension de vos tests.
  3. Tous les tests devraient permettre de différencier les bons programmes des mauvais programmes et de ne pas être redondants.
  4. Testez à plusieurs niveaux et à plusieurs portées, là où cela a du sens.
  5. Faire la distinction entre TDD, BDD, ATTD et cetera n’est pas aussi important que de tester votre logiciel pour en apprendre davantage à ce sujet. Qui se soucie de comment vous l'appelez?

[13:11] Mais il y a beaucoup plus de choses intéressantes dans cette interview. Vérifie s'il te plaît. Les notes d’affichage peuvent être trouvées sur pythontesting.net/23. Cet épisode vous a été présenté par les supporters de Patreon. Rendez-vous sur pythontesting.net/support pour plus d'informations ou rendez-vous directement sur patreon.com/testpodcast afin de continuer à diffuser l'émission. Sur Twitter, je suis @brianokken, et l'émission est @testpodcast. Merci pour l'écoute. [music]

[ad_2]