Tests unitaires L'équipe de débutants doit effectuer des tests unitaires

Je travaille avec une nouvelle équipe qui, historiquement, n'a effectué AUCUN test unitaire. Mon objectif est que l'équipe utilise éventuellement TDD (Test Driven Development) comme processus naturel. Mais comme TDD représente un changement radical de mentalité pour une équipe de tests non unitaires, je pensais commencer par écrire des tests unitaires après le codage.

Quelqu'un at-il été dans une situation similaire? Quel est un moyen efficace de mettre une équipe à l'aise avec TDD quand elle n'a effectué aucun test unitaire? Cela a-t-il un sens de faire cela en quelques étapes? Ou devrions-nous plonger directement et faire face à toutes les douleurs de croissance à la fois ??

MODIFIER

Juste pour clarifier les choses, il n’ya personne dans l’équipe (à part moi) qui ait TOUTE exposition ou expérience des tests par unité. Et nous prévoyons d’utiliser la fonctionnalité de test unitaire intégrée à Visual Studio.

Pratique sur les bugs / défauts existants.

C'est une situation vraiment difficile. Je ne suis jamais allé au TDD de rien avant, mais d'après mon expérience, amener une équipe à passer de tests unitaires à l'écriture de manière proactive a été une approche très "étape par étape".

Tout d’abord, mettez-les à l’aise pour écrire des tests unitaires et savoir réellement ce qu’ils sont et leurs avantages. Pour mes équipes, il était préférable d'écrire des tests unitaires pour les bogues existants. Les bogues actuels dans les systèmes ont deux choses que vous devez apprendre aux gens à bien écrire les tests unitaires:

1. une condition préalable et postcondition attendue
2. un résultat qui n'est pas ce qui est attendu actuellement et qui viole cette condition préalable / postcondition

Cela donne aux membres des exemples de pratique très concrets. Ils peuvent écrire un test avant de corriger le bogue, afin qu'il échoue. Ensuite, ils peuvent corriger le code afin qu'il passe et corrige le bogue. Une fois qu'ils sont à l'aise avec cela, vous pouvez les obtenir le reste du processus afin qu'ils puissent écrire des tests unitaires sans code à l'avance, puis écrire un nouveau code pour que leurs tests réussissent.

Je pense que le truc est de leur donner quelque chose à pratiquer là où il y a une méthode claire pré / post-conditions. Si les exigences relatives aux méthodes sont floues, il est difficile, même pour les personnes expérimentées en TDD, de savoir par où commencer. Faites un pas à la fois et vous y arriverez. Bonne chance!

J'ai réussi à convaincre toute mon entreprise de passer à TDD. Ce n’était pas facile, mais les efforts en valaient la peine: la qualité du code s’est améliorée après la transition, et personne n’imagine que l’on puisse revenir à l’horrible époque de codage des cow-boys.

1. Expliquez, expliquez, expliquez. Vous ne voulez pas que votre équipe écrive des tests. Vous voulez que votre équipe veuille écrire des tests. Cela signifie qu'ils doivent comprendre parfaitement pourquoi ils devraient le faire, quels en sont les avantages et comment cela leur facilitera beaucoup le travail. Red, Green, Refactor , écrivant un test de régression comme preuve qu'un bogue a été corrigé, etc. Vous devez les convaincre que tout cela a du sens avant de leur demander d'écrire du code.

2. Optez pour la vraie chose (premiers tests, puis code). Écrire des tests après le code n'a guère de sens, car vous ne saurez jamais s'ils fonctionnent réellement (et les gens écrivent des cas de tests bogués). Mon intuition est que la quantité d'effort nécessaire pour passer d' un test à un autre test est bien moindre que celle requise pour passer d' un test à l'autre sans code, puis dans les tests . Vous pouvez donc aussi sauter l'étape intermédiaire.

3. Commencez par des tests de régression. Celles-ci sont assez simples à comprendre et donnent une gratification instantanée. Bien entendu, cela suppose que le code soit correctement modularisé et facilement testable. Sinon, ignorez cette étape.

4. Faites des pas de bébé. Le TDD met un certain temps à s’habituer et peut être frustrant au début. Essayez d’introduire des tests dans un tout nouveau projet ou composant, idéalement: quelque chose de pas très important. Vous voulez éviter à tout prix la situation quand il y a quelque chose de très important à faire très rapidement et que les programmeurs ont le sentiment que TDD est un obstacle.

5. Lorsque l'équipe commence à être à l'aise, écrivez toutes les nouvelles fonctionnalités de manière TDD. Cela dépend de la taille de votre projet, mais après un certain temps, vous devriez obtenir une assez bonne couverture, avec seulement quelques parties héritées de votre projet écrites à l'ancienne.

6. À ce stade, l'équipe doit déjà comprendre et adopter le TDD, et les éléments hérités (non-TDD) doivent être considérés comme difficiles et gênants. Faites-le reformuler: la plupart des gens le feront avec plaisir.

Quelques autres points importants:

• Assurez-vous que vous utilisez le meilleur framework de test disponible. Il sera beaucoup plus difficile de convaincre les gens de faire du TDD s’ils doivent interagir avec une bibliothèque mal écrite.

• Assurez-vous que les tests sont faciles à exécuter et ne prennent pas trop de temps (ou trichez, par exemple, en utilisant une base de données en mémoire pour les tests).

• Installez un logiciel d’intégration continue afin que les tests rompus soient immédiatement détectés.

Une façon de se familiariser avec TDD consiste à écrire d’abord des tests d’intégration. Introduisez les coutures de test et les vrais tests unitaires plus tard.

Le problème avec l'écriture de tests unitaires après le codage est que le code peut ne pas être nécessairement conçu pour pouvoir être testé . Vous devrez peut-être refacturer ou peut-être revoir la conception pour introduire les coutures de test. Mais comment pouvez-vous refactoriser ou repenser en toute sécurité si vous n’avez aucune couverture de test ?

Les tests d'intégration peuvent vous fournir cette couverture au départ. Chaque fois que vous rencontrez un problème de régression ou de production, corrigez-le dans le code et couvrez ce code avec un test. Une fois que vous avez suffisamment de filet de sécurité fourni par ces tests, vous pouvez introduire des tests unitaires de composants isolés et / ou de classes plus fines de votre système.

TDD est très difficile à mettre en œuvre et n’est pas toujours la meilleure option pour toutes les équipes de développement. Dans mon travail précédent, l'équipe était fortement concentrée sur le TDD. Notre modèle de développement était entièrement TDD, utilisant l'approche de développement agile. Les tests ont été réalisés à l'aide de tests unitaires Visual Studio.

Si un développeur n'écrit aucun test unitaire pour sa fonctionnalité, il aurait des problèmes avec le fil technique. De plus, si quelqu'un vérifie une version endommagée ou des tests unitaires, le développeur doit résoudre tous les problèmes et ajouter 1 $ au pot d'argent de l'équipe.

Juste une petite chose à ajouter, visualisez le processus. Faites des tests d’intégration continue automatiquement et vérifiez la couverture de code. Répertoriez les modules testés les plus complets sur une page de démarrage visible par tous. Cela devrait faire avancer la compétition par équipes.

Je suis passé d'une expérience JUnit directe à TDD, expérience qui a clairement fait ressortir la valeur de TDD. Je suis devenu si reconnaissant pour les tests unitaires que je suis rapidement devenu un évangéliste pour cette approche.

Je faisais partie d'équipes qui n'ont effectué aucun test unitaire, mais le test a été introduit et il est devenu presque courant de faire des tests maintenant. Je suggérerais d'explorer dans quelle mesure votre équipe comprend-elle les bases du test unitaire et quels outils voulez-vous apporter ici?

Dans mon cas, cela impliquait d'introduire nUnit dans du code .Net, mélange de logique métier, d'interface utilisateur et de fonctionnalités dorsales. Je suggérerais de voir s'il y a des gens qui sont plus enclins à vouloir y aller plus que d'autres afin que quelques membres de l'équipe l'obtiennent et que cela se propage un peu mieux que le revers où vous essayez de faire en sorte que tout le monde pour sauter sur cela. En faisant en sorte que certains le fassent bien en premier, cela permet un certain entraînement croisé, de sorte que ceux qui le prennent peuvent être testés pour savoir s'ils peuvent bien enseigner à quelqu'un d'autre.

Un autre point est d’envisager de faire venir ceux qui ont plus d’expertise pour essayer de le montrer dans une certaine mesure. Thoughtworks a été amené là où je travaille pour nous montrer des éléments qui ont été largement adoptés et d’autres moins, mais je pense que ce serait le cas dans la plupart des endroits.