La chose la plus importante à transmettre lors de l’enseignement du TDD [fermé]

Question

Je collabore avec un groupe de professionnels en vue d'organiser un événement pour aider à enseigner la pratique du TDD aux personnes intéressées mais n'ayant aucune expérience (novices).

Nous essayons de créer des laboratoires, des ateliers, etc., et j'essaie de penser à la chose la plus importante que nous devons transmettre à ces personnes pour les aider à réussir dans la pratique du TDD.

Selon vous, que devrions-nous faire de notre priorité d’apprentissage? Quel aspect de l’enseignement du TDD est le le plus important. Si vous devez faire deux choses, ça va, je ne vous retiendra pas à la SEULE partie:)

Answer 1

C'est une question de design . Ce n'est PAS sur les tests.

Answer 2

Ne sautez pas les étapes du processus. Il faut plus de temps pour entrer dans le groove initial de TDD, mais une fois en place, le SDLC dans son ensemble est plus rapide et bien plus sans bug.

Rouge - Vert - Refactor - > juste le faire.

Answer 3

Ce n'est pas parce que vos tests réussissent que le code est correct.

À part cela, je dirais qu’il est important d’envisager les tests dans votre conception. Si votre code est difficile à tester sans une connaissance intime de la mise en œuvre interne de l'unité testée, vous souhaiterez peut-être revoir la conception. Sinon, la refactorisation devient plus risquée car les tests doivent probablement être modifiés avec le code.

Answer 4

Je ne sais pas si cela compterait comme la chose la plus importante, mais c'est quelque chose qui m'a pris du temps pour "obtenir". quand j'ai exploré pour la première fois en utilisant TDD.

N'écrivez pas le code dans votre tête avant de passer le test.

Quand j'ai commencé à utiliser le TDD, je savais " ce que le design devrait être. Je savais " quel code je voulais écrire. J'ai donc écrit un test qui me permettrait d'écrire ce morceau de code.

Quand je faisais cela, je ne faisais pas vraiment de TDD, car j’écrivais le code en premier (même si le code n’était que dans ma tête: -)

Il m'a fallu un certain temps (et quelques astuces de personnes intelligentes) pour comprendre que vous deviez vous concentrer sur le test. Ecrivez le test correspondant au comportement souhaité - puis rédigez le code minimal nécessaire pour le faire passer - puis laissez la conception émerger via le refactoring. Répéter jusqu'à la fin.

Answer 5

Je suggère, "Soyez patient." Ça fait bizarre au début. Pour moi, c’était probablement trois projets avant que cela ne paraisse naturel.

Answer 6

Je suis d'accord avec ce que Jon a déclaré dans sa réponse , mais je pense qu'un corollaire important est que la testabilité ne dicte pas "un bon design" , mais est seulement un indicateur. que votre conception sur la cible.

Answer 7

TDD, dans mon esprit, est tout au sujet du rythme (rouge, vert, refactor). Obtenir le rythme vous permet de surmonter la "bosse". de "ne pas l'obtenir". Et si vous ne suivez pas le rythme, vous ne collerez probablement pas à la TDD très longtemps. L'essence du rythme est constituée de pas de bébé, ce qui a déjà été mentionné. Écrivez le moins de code possible et refactorisez sans merci.

Une chose sur laquelle insister est que TDD échange des gains à court terme contre des gains à long terme. Le fait de commencer avec TDD réduira invariablement votre productivité. Mais une fois que vous avez appris le rythme, cela équivaut à entrer dans un groove et cela peut réellement vous aider à travailler plus rapidement. Sans parler de l’effet secondaire du TDD, il s’agit d’un nombre croissant de tests unitaires qui fournissent des tests de régression. Un logiciel est inévitable: les systèmes en cours de maintenance (sans série de tests de régression automatisés) se dégradent avec le temps.

Answer 8

Insistez sur le fait que TDD représente un changement de paradigme pour les développeurs . Si vous représentez une nouvelle équipe, sachez qu'il faudra jusqu'à six mois pour que l'équipe soit pleinement efficace en tant que praticiens du TDD. Une fois que vous avez une équipe agile mature pratiquant efficacement le TDD, le jumelage permettra à un nouveau développeur d’entrer dans le vif du sujet après quelques itérations. De plus, en utilisant des paires d’une équipe pour créer une nouvelle ligne, vous pouvez obtenir une nouvelle ligne plus rapide que la première ligne.

Dans les projets que nous avons mesurés, nous avons constaté une diminution de six fois le nombre de défauts détectés lors des tests fonctionnels / de régression automatisés une fois que l’équipe a appris à effectuer le TDD. C'est une économie importante. De plus, le code reflète une conception plus nette, avec moins de lignes de code pour chaque fonctionnalité. TDD mais un arrêt virtuel du placage d’or. Le TDD est plus efficace si vos cartes de scénario ont des critères d’acceptation.

Le TDD permet également un rythme soutenu. L'équipe constatera qu'elle peut continuer à obtenir le même nombre de fonctionnalités à chaque itération car le code reste propre avec peu de défauts. Avec TDD et le test fonctionnel / de régression automatisé, nous constatons souvent qu’aucun défaut n’a été détecté lors du test d’acceptation de l’utilisateur.

Answer 9

Faire face au besoin de laisser tomber TDD lorsque les délais sont serrés. C’est l’un des plus gros problèmes auxquels j’ai été confronté en aidant des personnes et des équipes avec TDD. Ils ont eu du mal à exprimer l’importance et la valeur de laisser tomber les éléments en vedette plutôt que les tests à des cadres supérieurs.

Answer 10

Procédez par petits pas.

Assurez-vous que vos tests ne couvrent qu'un très petit domaine et, comme le dit PhlipCPP: ' Effectuez l'EDITE MINIMAL nécessaire pour réussir le test. '

Même dans ce cas, TDD a beaucoup à faire. Vous devez donc vous assurer de ne rien manquer.

Answer 11

D'après mon expérience, l'utilisation de TDD permet à mon équipe et à moi-même de refactoriser sans pitié notre code sans craindre qu'il ne casse quelque chose d'inattendu.

Donc, je suppose que l’aspect le plus important de la TDD est la couverture, puisqu’une bonne couverture me donne l’assurance de refactoriser chaque fois que je vois un point dans la base de code qui peut l’utiliser.

Answer 12

Mettez l'accent sur différents types de tests. Le test de la boîte noire et le test de la boîte blanche sont importants et ont des objectifs différents. Les tests en boîte blanche ne sont pas là pour vérifier l'exactitude, car ils ne peuvent pas tester l'ensemble du système. Il est là pour rendre les odeurs de code encore plus puantes et ainsi fournir une meilleure direction de refactoring. Le test de la boîte noire est là pour vérifier l'exactitude. Chaque fonctionnalité doit être testée dans la boîte noire.

Soulignez également les différences de couverture des tests. En raison de problèmes de combinatoire et de répétabilité, il est impossible de tester tous les chemins de code de votre application dans une boîte noire. Ma règle est qu'une fonctionnalité n'est pas complète tant qu'elle n'a pas été testée en boîte noire. Vous devriez aider les élèves à comprendre leurs propres règles. Cependant, les tests en boîte blanche ne doivent pas avoir de dépendances de classe externes; par conséquent, chaque ligne de chaque classe doit être testée en boîte blanche.