Une suggestion que je ferais est de commencer un groupe coding Dojo. Il permet de démarrer TDD à partir de zéro avec un groupe, avec la plupart des meilleures pratiques recommandées et se concentrer sur TDD. Son idée de base est de relever un défi simple (comme un programme qui transforme les chaînes d'algarismes romains en ints), et de commencer à le coder, en commençant par de simples entrées, et en codant seulement quand un test échoue. Ce n'est pas le but de tout ceci de mettre fin au problème, mais de commencer à le faire correctement.
Voici une autre link à ce sujet, dont je récupérai la partie suivante:
- Il y a un problème de codage qui est annoncée à l'avance.
- Il y a une pièce avec un ordinateur relié à l'écran vidéo.
- Le présentateur explique le défi de codage et commence le codage. Le présentateur peut ou non choisir d'avoir un copilote. S'il s'agit d'une session Randori, un copilote est généralement assigné de sorte que lorsque le changement se produit, le copilote prend la relève du codeur.
- Une moitié de la paire est changée toutes les 5 minutes si la session est Randori.
- Le codeur doit continuellement expliquer ce qu'il fait.
- Le codeur doit s'arrêter lorsque quelqu'un du public tombe du chariot (il a une question sur la compréhension de ce que la paire est en train de faire) - et ne continue que lorsque cette personne est de nouveau sur la bonne voie.
- Tous les codeurs utilisent TDD (Test Driven Development).
- Tout le code produit sera rendu public en utilisant la licence publique commune Eclipse.
- Le langage de programmation à utiliser est annoncé à l'avance par session.
Je pense que votre meilleur pari est de faire équipe avec les membres de l'équipe, en disant: "Aujourd'hui, nous allons essayer le premier problème pour résoudre le problème d'aujourd'hui, afin que vous ayez une idée de TDD." Ensuite, dans la présentation, il suffit de travailler un exemple modeste. L'expérience est la meilleure; le voir, deuxième meilleur. Entendre à ce sujet, pas si bon. –