Comment avez-vous convaincu votre responsable de vous laisser tester vos unités?

Par "utilisation", j'entends être autorisé à développer, à enregistrer pour contrôler la source et à maintenir les tests unitaires au fil du temps, etc.

Les objections typiques de la direction sont:

1. Le client n'a pas payé pour les tests unitaires
2. Le projet ne laisse pas de temps pour les tests unitaires
3. Dette technique? Quelle dette technique?

Connaissez-vous d'autres objections? Quelles ont été vos réponses?

Merci d'avance!

J'ai rencontré ce problème récemment lorsqu'un client utilisait notre méthodologie, mais la direction supérieure a eu vent que les développeurs passaient leur temps à tester et non à développer et étaient préoccupés par cela - après tout, ils avaient du personnel d'assurance qualité pour faire les tests! J'ai blogué sur la façon dont je l'ai traité ici:

http://practicalagility.com/show-them-the-numbers-its-results-that-matter/

Pour résumer, j'ai comparé nos heures estimées aux heures réelles du projet, puis notre taux de défauts par rapport au taux de défauts d'autres équipes. Dans notre cas, ces chiffres se comparaient favorablement et il n'y avait plus de problèmes.

Ma conclusion basée sur cette expérience est la suivante:

... le meilleur moyen de convaincre quiconque que votre approche de la chose est pratique et pragmatique est de le faire et de le comparer à d'autres approches. Les gens ne se soucient pas du dogme ou de la raison pour laquelle vous pensez que quelque chose devrait être la meilleure solution. Ce n’est qu’en montrant aux gens les chiffres et en mesurant l’efficacité de votre approche que vous pourrez réellement démontrer que vos pratiques sont efficaces.

Sur d’autres projets, nous avons travaillé avec des développeurs clients qui n’avaient ni créé de tests unitaires ni TDD, et nous avons dû maintenir des tests qu’ils ont subis. Cependant, il devient très facile de vendre l'approche TDD à ces développeurs lorsque vous pouvez leur dire ce qu'ils ont cassé dans le code avant qu'ils ne le sachent!

Donc, dans votre cas, je le ferais discrètement si nécessaire (peut-être y a-t-il une petite partie du code que vous pouvez commencer à tester et qui change souvent ou dont vous êtes responsable), mais gardez une trace de vos chiffres - quel est le effort pour créer vos tests? Quel est le taux de défaut? Comment cela se compare-t-il avec d'autres projets / membres de l'équipe?

À mon avis, personne ne devrait demander la permission ou présenter des excuses pour vouloir faire son travail correctement et tout développeur professionnel devrait essayer de tester son code avec des tests automatisés chaque fois que cela est possible et pratique. Espérons que ce soit ces deux choses dans votre cas. Bonne chance!

Afficher le retour sur investissement (ROI)

Écrire des tests automatisés prend du temps. Une fois que. L'exécution de tests automatisés ne prend pas de temps, car vous pouvez faire autre chose en cours d'exécution.

Exemple: Le test manuel de la fonctionnalité X prend 30 minutes. L'écriture d'un test automatisé prendrait 1 heure. Même si nous n'avons pas de bogues, nous devrons tester la fonctionnalité X dix fois au cours du projet, car ses couches et ses composants dépendants sont modifiés. Donc, automatiser le test de la fonctionnalité X nous fera gagner 4 heures sur la durée de vie du projet.

En réalité, c’est quand vous avez un bogue que les tests automatisés rapportent vraiment. En premier lieu, ils détectent les bogues tôt et à bon marché, ce qui permet d’économiser du temps et de la gêne. Deuxièmement, si vous avez un bogue difficile et passez par de nombreux cycles de test de construction de code pour le résoudre, le temps gagné par rapport aux tests manuels s’ajoute une rapidité extraordinaire.

Les entreprises comprennent économiser du temps et de l’argent. Voilà comment le vendre.

Si vous les avez déjà confrontés et qu'ils ne sont pas d'accord avec cela, mais que vous ne vous sentez pas à l'aise pour écrire du code sans eux ... alors ne posez plus la question. Il suffit d’écrire et de ne pas les enregistrer.

La direction ne compte pas les lignes de code, mais verra que tous vos enregistrements ont des taux de réussite plus élevés de la part du contrôle qualité (ou des clients) et ils finiront par demander pourquoi ... alors vous pouvez être comme "BAM! TDD". ! "

Vous ne jouez pas avec le projet, le processus ou la source ... donc je ne vois pas de raison négative. Honnêtement, je ne vois pas pourquoi cela serait différent en termes de temps que d'exécuter tous vos tests d'exécution, de saisie et de contrôle manuels.

1) Le client n'a pas payé pour les tests unitaires

Le client (pensait qu'ils payaient) pour une solution efficace. Selon les contrats, la réparation des défauts peut être réellement rentable pour votre entreprise. S'il y a suffisamment de blocage. Revenons donc à payer pour une solution efficace. TDD devrait contribuer à cet objectif.

2) Le projet ne laisse pas de temps pour le TDD

TDD ne prend pas plus longtemps. Cela devrait permettre de réduire la quantité de code superflu ou superflu et de centrer la base de code sur ce qui fait passer les tests. Tous les tests réussis, sous réserve de la qualité et de la pertinence des tests, signifient que le code est terminé.

3) Dette technique? Quelle dette technique?

J'ai l'impression que vous êtes peut-être en train de demander l'ajout rétrospectif de tests au code existant. Ceci est un cauchemar vendre dans le meilleur des cas et n'apporte pas les avantages que vous pourriez attendre. Cependant, l'ajout de tests au fur et à mesure que vous corrigez des bugs devrait être acceptable et aider à long terme.

De toute façon, je ne recommande pas d'écrire les tests comme Snorfus l'a suggéré. Il semble bien en théorie, mais les tests unitaires peux et faire le changement au fil du temps. À mesure que les exigences changent, de nouvelles fonctionnalités sont ajoutées et les tests unitaires doivent être mis à jour. Si vous travaillez en équipe, vos tests unitaires deviendront obsolètes à mesure que d'autres ajouteront des fonctionnalités / correctifs.

Je traite des points spécifiques que vous avez mentionnés plutôt que d'en aborder de nouveaux car il y a une marge de manœuvre pour progresser ou pour comprendre pourquoi il est bloqué.

Pour chaque client confronté à des problèmes de production,

1. Ecrivez un test d'unité et envoyez un courrier électronique au responsable indiquant que vous avez ajouté un test d'unité pour couvrir le scénario.

2. Et dites-lui que ce problème ne se reproduira plus dans la production car notre test unitaire est exécuté tous les soirs et nous le saurons avant que le code ne passe en production en observant l'échec de ce test.

3. Dites-lui que si nous avions déjà mis en place ce test unitaire avant la production du code, ce problème de production ne serait jamais arrivé.

Faites-le de manière constante et persistante et bientôt il sera convaincu. Les gestionnaires n'aiment pas que le client soit confronté à des problèmes de production et il souscrira à l'idée de tests unitaires. Bonne chance.