J'ai fait TDD depuis 3 ans. Nous étions une petite entreprise et nous avons eu un soutien très solide pour la plupart des aspects du processus agile de la direction. Tout le monde sur l'équipe de développement a été vendu sur le processus. Et ainsi, l'investissement initial que cela prend habituellement pour créer des luminaires a été accepté en sachant que cela rembourserait le chemin. (Code qui démarre un serveur HTTP, code qui remplit des bases de données SQL avant des tests, etc.). Documentation surtout produit dans les tests et les demandes d'aide étaient généralement présentées sous la forme d'un test défaillant.
Maintenant, j'ai déménagé à une plus grande entreprise et que la direction est favorable au processus agile, les coéquipiers sont un sac mixte, certains d'entre eux le voient utile, certains d'entre eux le font à cause de la direction et d'autres ne voient pas la valeur . Cela a été un défi de convaincre les gens de passer un peu de temps à construire des luminaires ou de convaincre un membre de l'équipe le meilleur moyen de l'aider s'il prenait le temps d'écrire un test défaillant.
Alors, que pensez-vous que c'est la meilleure façon de vendre TDD à un coéquipier hésitant? Les objections sont généralement: «C'est un coût inutile», nous pouvons toujours écrire des tests après le fait que des pièces importantes «, c'est un mot de buzz, les équipes le ramassent, puis il tombe sur le côté car la forte broyage commence 'etc.
6 Réponses :
simple - maintenabilité. TDD vous permet de modifier les modifications et de voir où ces changements affectent le reste du code. Plus la base de code est grande, plus il est impératif qu'il y ait des tests pour valider les nouveaux changements.
Correcless. Bien que les tests soient eux-mêmes cassés, ils atteignent finalement un point où ils s'assurent que les composants font ce qu'ils sont censés. Mieux le développeur, plus c'est plus rapide.
Un autre avantage est que TDD informe la conception des composants du système. Si vous essayez de tester quelque chose et que le test est trop compliqué, cela signifie probablement que vous devez casser le problème dans des parties plus petites ...
Pour le vendre aux personnes, vous dites que, à long terme, il fait d'ajouter de nouvelles fonctionnalités moins chères et de réduire le risque de casser la fonctionnalité existante. Donc, cela réduit les coûts.
Eh bien, tout ce qui précède concerne l'avantage de faire des tests, sans utiliser des tests - premièrement comme moyen de codage. Mon équipe obtient déjà pourquoi elles ont besoin de couvrir (au moins la part éminente) de leur code avec des tests.
Oui, mais vous pouvez vendre les avantages.
"Le meilleur moyen de vendre TDD à un coéquipier hésitant"
vous ne pouvez pas. Ne perdez pas de temps "Vendre".
Au lieu de cela, investissez du temps dans "Prouvage".
juste le faire. Avoir du succès. Quand les gens demandent quel est le secret de votre succès, alors révéler le TDD. Pas avant.
C'est bon à. Certaines personnes que vous ne pouvez pas convaincre.
Les actions parlent beaucoup plus fort que les mots. Ceci est définitivement une situation où les sceptiques doivent être convaincus par une démonstration.
Je peux essayer cela, il serait douloureux de continuer à travailler sur le code partagé.
@ hivermaster: "Il serait douloureux de continuer à travailler sur le code partagé" Pourquoi?
@ S.Lott: Vous entrez, vous réparez un bug en créant un test qui répond à cette affaire, avec une moqueuse et un luminaire quelque peu élaboré, seulement pour que cela soit ignoré lorsque quelqu'un d'autre corrige un bogue / ajoute une fonctionnalité plus tard dans le même code et quitte le test cassé ...
@ stipsmaster: Je n'obtiens pas comment c'est plus douloureux qu'aucun TDD du tout.
@ S.Lott: Bien sûr que ce n'est pas :), désolé si j'ai donné cette impression.
Je pense Le message de Joel explique très bien pourquoi le test est une bonne chose ™.
Je ne pense pas qu'il utilise jamais la phrase "TDD", mais il a de superbes infos.
Le test n'est pas le même que TDD. Tout le monde sera d'accord sur l'importance des tests. La philosophie de développement de TDD est une autre histoire, malgré l'hypothèse de l'OP selon laquelle c'est nécessairement la seule vraie façon.
Je suis vraiment d'accord. Cependant, d'après ce que je sais de TDD, les approches postales de Joel (asymptotiquement?) Un argument pour TDD
@ user275455: Ce n'est pas nécessairement le seul moyen, c'est tout simplement dans mon cas (et à mon avis) beaucoup plus productif que le Hodge-Podge qui existe dans mon environnement actuellement.
Pour le coéquipier hésitant, soyez patient, attendez une opportunité, puis bondez. Dans le développement de logiciels, il y aura sans aucun doute un problème dans lequel TDD aurait empêché ou atténuer le problème. Être à la recherche d'une telle opportunité. Travailler avec lui / elle pour créer un test (s) qui aurait dû être développé depuis le début. Cependant, assurez-vous de créer votre message de manière à ne pas embarrasser votre coéquipier.
Je suis d'accord avec S. Lott , vous ne pouvez pas "vendre" eux, vous devez montrer la valeur.
L'un des moyens les plus efficaces de le faire est la programmation par paire. Nous avons accordé une autre "vente" problématique convaincant les personnes que ce appariement est une approche efficace, mais après un certain temps, vous pouvez convaincre / convertir un développeur ou aussi.
TDD était un concept difficile pour moi initialement, mais maintenant je ne peux pas imager la programmation d'une autre manière.
montre-leur ce site: wedoDDD.com - étuis d'utilisation de la société actuelle. Ceux qui pratiquent avec succès TDD dans des entreprises réelles.
Dupliquer de nombreux de ceux-ci: Stackoverflow.com/search?q=tddyRII
Vous avez abordé quelque chose qui m'a dérangé depuis que j'ai commencé à travailler sur des équipes. Pourquoi est-ce que nous devons parfois "vendre" des développeurs sur de bonnes pratiques? Ils n'ont sûrement jamais eu la permission de leurs mauvaises habitudes inutiles.
Dupliqué possible de Comment encourager la mise en œuvre de TDD? et beaucoup d'autres.