unit-testing - tutorial - testing unit




TDD vs. Unit testing (12)

Ma société est assez récente pour tester notre code. J'ai lu sur le TDD et les tests unitaires depuis un certain temps et je suis convaincu de leur valeur. J'ai essayé de convaincre notre équipe que TDD valait la peine d'apprendre et de changer nos mentalités sur la façon dont nous programmons, mais c'est un combat. Ce qui m'amène à ma question (s).

Il y a beaucoup de membres de la communauté TDD qui sont très attachés à écrire le test, puis le code (et je suis avec eux), mais pour une équipe qui a des difficultés avec TDD, un compromis apporte-t-il encore des avantages?

Je peux probablement réussir à faire en sorte que l'équipe écrive des tests unitaires une fois le code écrit (peut-être comme une exigence de vérification de code) et je suppose qu'il y a toujours de la valeur dans l'écriture de ces tests unitaires.

Quelle est la meilleure façon d'amener une équipe en difficulté dans TDD? Et à défaut, cela vaut-il encore la peine d'écrire des tests unitaires même si c'est après que le code a été écrit?

MODIFIER

Ce que j'ai retenu de cela, c'est qu'il est important pour nous de commencer les tests unitaires, quelque part dans le processus de codage. Pour les membres de l'équipe qui choisissent le concept, commencez à vous diriger vers le TDD et les tests. Merci pour la contribution de tout le monde.

SUIVRE

Nous avons récemment commencé un nouveau petit projet et une petite partie de l'équipe a utilisé TDD, le reste a écrit des tests unitaires après le code. Après avoir terminé la partie codage du projet, ceux qui ont écrit les tests unitaires après le code ont été surpris de voir les codeurs TDD déjà réalisés et avec un code plus solide. C'était un bon moyen de convaincre les sceptiques. Nous avons encore beaucoup de douleurs de croissance à venir, mais la bataille des volontés semble être terminée. Merci à tous ceux qui ont offert des conseils!


Je peux probablement réussir à faire en sorte que l'équipe écrive des tests unitaires une fois le code écrit (peut-être comme une exigence de vérification de code) et je suppose qu'il y a toujours de la valeur dans l'écriture de ces tests unitaires.

Il n'y a absolument aucun doute sur le fait qu'il y a de la valeur dans le code testé unitaire (indépendamment du moment où les tests ont été écrits) et j'inclue "le code est testé unitairement" dans la "Définition de Done". Les gens peuvent utiliser TDD ou non, aussi longtemps qu'ils testent.

En ce qui concerne le contrôle de version, j'aime utiliser des " branches de développement " avec une politique testée unitairement (ie le code compile et construit, tous les tests unitaires passent). Lorsque les fonctionnalités sont terminées, elles sont publiées depuis les branches de développement vers le tronc. En d'autres termes, la branche du tronc est la " Done branch " (Pas de rebut sur le tronc!) Et a une politique expédiable (peut être libérée à tout moment) qui est plus stricte et inclut plus de choses que "unit tested".


C'est quelque chose que votre équipe devra avoir ses propres succès avant de commencer à y croire. Je vais raconter mon histoire de nUnit pour tous ceux qui se soucient de:

Il y a environ 5 ans, j'ai découvert nUnit lorsque je travaillais sur un projet. Nous avions presque terminé V1.0 et j'ai créé quelques tests juste pour essayer ce nouvel outil. Nous avons eu beaucoup de bogues (évidemment!) Parce que nous étions une nouvelle équipe, sur une date limite serrée, des attentes élevées (sonnent familier?) Etc. De toute façon nous avons obtenu 1.0 et commencé sur 1.1. Nous avons réorganisé un peu l'équipe et 2 devs m'ont été assignés. J'ai fait une démonstration d'une heure pour eux et je leur ai dit que tout ce que nous avions écrit devait être testé. Nous avons constamment couru "derrière" le reste de l'équipe pendant le cycle 1.1 dev car nous écrivions plus de code, les tests unitaires. Nous avons fini par travailler plus mais voici la récompense - quand nous avons finalement commencé à tester nous avions exactement 0 bugs dans notre code. Nous avons aidé tout le monde à déboguer et réparer leurs bugs. Dans le post-mortem, quand le nombre de bugs est apparu, cela a attiré l'attention de TOUS.

Je ne suis pas assez stupide pour penser que vous pouvez tester votre chemin vers le succès, mais je suis un vrai croyant quand il s'agit de tests unitaires. Le projet a adopté nUnit et s'est rapidement étendu à l'entreprise pour tous les projets .Net suite à 1 succès. La période de temps totale pour notre version V1.1 était de 9 dev, donc ce n'était certainement pas un succès du jour au lendemain. Mais à long terme, cela a été un succès pour notre projet et pour l'entreprise pour laquelle nous avons construit des solutions.


Eh bien, si vous n'écrivez pas les premiers tests, ce n'est pas "Test Driven", c'est juste un test. Il a des avantages en soi et si vous avez déjà une base de code, ajouter des tests est certainement utile, même si ce n'est pas un TDD mais simplement un test.

Rédiger des tests consiste d'abord à se concentrer sur ce que le code devrait faire avant de l'écrire. Oui, vous faites aussi un test et c'est bien, mais certains peuvent prétendre que ce n'est même pas le point le plus important.

Ce que je ferais est de former l'équipe sur des projets de jouets comme ceux-ci (voir Codage Dojo, Katas) en utilisant TDD (si vous pouvez faire participer des programmeurs TDD expérimentés à un tel atelier, ce serait encore mieux). Quand ils verront les avantages, ils utiliseront TDD pour le vrai projet. Mais en attendant ne les forcez pas, ils ne voient pas l'avantage qu'ils ne le feront pas correctement.


Il ne fait aucun doute que tester (First, While ou même After) permettra de sauver votre bacon, et d'améliorer votre productivité et votre confiance. Je recommande de l'adopter!

J'étais dans une situation similaire, parce que j'étais un développeur "noob", j'étais souvent frustré quand je travaillais sur un projet d'équipe par le fait qu'une contribution avait brisé la construction. Je ne savais pas si j'étais à blâmer ou même dans certains cas, à qui blâmer. Mais j'étais plus préoccupé que je faisais la même chose à mes collègues développeurs. Cette prise de conscience a ensuite motivé l'adoption de certaines stratégies TDD. Notre équipe a commencé à avoir des jeux idiots, et des règles, comme si vous ne pouviez rentrer à la maison qu'après tous vos tests, ou si vous soumettez quelque chose sans test, vous devez acheter tout le monde "bière / déjeuner / etc".


Je l'ai fait dans de nombreuses organisations et j'ai trouvé que la meilleure façon de démarrer et de suivre TDD est de mettre en place une programmation par paire. Si vous avez quelqu'un d'autre sur qui vous pouvez compter, alors vous pouvez vous séparer et faire équipe avec d'autres développeurs pour faire une programmation couplée en utilisant TDD. Sinon, je formerais quelqu'un qui vous aidera à le faire avant de le présenter au reste de l'équipe.

L'un des principaux obstacles aux tests unitaires, et en particulier au TDD, est que les développeurs ne savent pas comment le faire, ils ne peuvent donc pas voir comment cela peut valoir leur temps. Aussi, lorsque vous démarrez pour la première fois, il est beaucoup plus lent et ne semble pas offrir d'avantages. Ce n'est que vraiment vous fournir des avantages quand vous êtes bon. En mettant en place des sessions de programmation jumelées, vous pouvez rapidement amener les développeurs à l'apprendre rapidement et à y parvenir plus rapidement. En outre, ils seront en mesure d'en voir les avantages immédiats tout en travaillant ensemble.

Cette approche a fonctionné plusieurs fois pour moi dans le passé.


Je lis juste ceci sur un calendrier: "Chaque règle, exécutée à son maximum, devient ridicule ou même dangereuse." Donc, ma suggestion n'est pas d'être religieux à ce sujet. Chaque membre de votre équipe doit trouver un équilibre entre ce qu'il ressent «bien» en ce qui concerne les tests. De cette façon, chaque membre de votre équipe sera plus productif (au lieu de, disons, en pensant "pourquoi dois-je écrire ce test sti ****?").

Donc, certains tests sont meilleurs que rien, les tests après le code valent mieux que quelques tests et tests avant que le code ne soit meilleur qu'après. Mais chaque étape a ses propres mérites et vous ne devriez pas froncer les sourcils même sur les petites étapes.


Si elles sont nouvelles pour les tests que l'OMI, commencez par tester le code qui a déjà été écrit et passez graduellement aux tests d'écriture. En tant que personne qui essaye d'apprendre le TDD et qui est nouveau dans les tests unitaires, j'ai trouvé difficile de faire un 180 complet et de changer de mentalité pour écrire des tests avant le code, donc l'approche que je prends est un mélange de 50-50 ; Quand je sais exactement à quoi ressemblera le code, je vais écrire le code et écrire un test pour le vérifier. Pour les situations où je ne suis pas tout à fait sûr alors je vais commencer par un test et travailler à rebours.

Souvenez-vous également qu'il n'y a rien de mal à écrire des tests pour vérifier le code, au lieu d'écrire du code pour satisfaire aux tests. Si votre équipe ne veut pas suivre la route TDD, ne la forcez pas.


Si l'équipe est en train de patauger lors de l'implémentation de TDD, mais qu'ils ne créaient pas de tests unitaires avant ... alors démarrez-les en créant des tests unitaires après l'écriture de leur code. Même les tests unitaires écrits après le code valent mieux que pas de tests unitaires!

Une fois qu'ils sont compétents en tests unitaires (et tout ce qui va avec), vous pouvez les amener à créer les tests en premier ... et le code en second.


TDD est sur le design! Donc, si vous l'utilisez, vous serez sûr d'avoir une conception testable de votre code, ce qui rend plus facile d'écrire vos tests. Si vous écrivez des tests après que le code a été écrit, ils sont toujours valables mais à mon humble avis, vous perdrez du temps puisque vous n'aurez probablement pas de modèle testable.

Une suggestion que je peux vous faire pour essayer de convaincre votre équipe d'adopter le TDD est d'utiliser certaines des techniques décrites dans le livre de Mary Linn et Linda Rising: Patterns for Introducing new ideas


TDD est un outil que les développeurs peuvent utiliser pour produire un meilleur code. Il me semble que l'exercice d'écriture de code testable est au moins aussi précieux que les tests eux-mêmes. Isoler l'IUT (implémentation testée) à des fins de test a l'effet secondaire de découpler votre code.

TDD n'est pas pour tout le monde, et il n'y a pas de magie qui permettra à une équipe de choisir de le faire. Le risque est que les rédacteurs de tests unitaires qui ne savent pas ce qui vaut la peine d'être testés écriront beaucoup de tests de faible valeur, ce qui sera de la chair à canon pour les sceptiques de TDD dans votre organisation.

Je fais généralement des tests d'acceptation automatisés non négociables, mais j'autorise les développeurs à adopter le TDD à leur convenance. J'ai mes TDDers formés / mentor le reste et "prouver" l'utilité par l'exemple sur une période de plusieurs mois.

C'est autant un changement social / culturel que technique.


Vous pouvez trouver un peu de traction en montrant un ou deux exemples où TDD entraîne moins de code écrit - parce que vous écrivez seulement le code requis pour faire passer le test, la tentation de plaquer or ou de vous engager dans YAGNI est plus facile à résister. Le code que vous n'écrivez pas n'a pas besoin d'être maintenu, refactorisé, etc., donc c'est une "vraie épargne" qui peut aider à vendre le concept de TDD.

Si vous pouvez démontrer clairement la valeur en termes de temps, coût, code et bugs enregistrés, vous pouvez trouver que c'est une vente plus facile.


À mon humble avis, il est préférable d'avoir une couverture de test de 50% avec «code first, test after» et une bibliothèque complète, une couverture de test de 100% et une bibliothèque complétée à 50% avec TDD. Après un certain temps, vos collègues développeurs trouveront divertissant et éducatif d'écrire des tests pour tout le code public qu'ils écrivent, afin que TDD se faufile dans leur routine de développement.







tdd