Faites bouger les choses sur TDD

Je fais partie d'une équipe de développeurs qui travaille avec de nombreuses autres équipes pour maintenir et améliorer une application utilisée depuis au moins 15 ans. Quand il a été construit et conçu pour la première fois, TDD était inconnu.

L'application est assez stable, et nous rencontrons rarement un bug d'arrêt de spectacle, mais nous faisons en moyenne un ou deux bugs par semaine, ce qui réduit sérieusement la qualité de service. Ces bogues prennent une éternité à trouver et à corriger, principalement à cause du doigt pointé, et le seul test que nous avons est le test d'interface. Parce qu'il y a beaucoup de temps perdu à chercher où le bogue est avant qu'il ne puisse être corrigé, moi et un autre développeur prévoyons de proposer le développement piloté par les tests. Il y a une nouvelle révision à venir bientôt, et nous aimerions voir des tests unitaires presque complets effectués sur les nouveaux modules, nous prévoyons également de suggérer la construction d'unités de test pour tout code que nous devons modifier qui est hérité (c.-à-d., Correction de bogue ou implémentation de fonctionnalités ), mais sans perdre de temps à développer des cas de test pour du code qui n'a pas causé de problèmes.

Cela me semble raisonnable. Ce mois-ci, nous avons eu un bug qui a pris plus de deux semaines à corriger, mais aurait pu être identifié avant le déploiement si des tests unitaires avaient été effectués. Mais pour nos gestionnaires, il semble qu'ils vont dépenser plus d'argent.

Comment convaincre nos clients qu'ils souhaitent dépenser de l'argent pour les tests unitaires et le développement piloté par les tests? Existe-t-il des études qui montrent le retour sur investissement des tests unitaires?

Incorporation directe de TDD à part entière dans un code hérité, le projet de maintenance est une vente très difficile. Voici une approche que j'ai très bien fonctionnée. Pour chaque bogue qui arrive, créez un test non unitaire automatisé qui illustre le bogue. Par «non-unité», je veux dire quelque chose qui peut toucher de nombreuses parties du système, toucher la base de données et le système de fichiers, etc. - mais par «automatisé», j'entends des exécutions sans interaction humaine. C'est le genre de test que vous voudrez dans votre suite de régression de toute façon. L'écrire accomplit beaucoup de choses: il vous permet de rendre le code testable, même à ce niveau très grossier, et il vous expose à la constellation de code qui pourrait avoir quelque chose à voir avec le bogue, donc il vous éduque et vous informe sur matériel très spécifiquement pertinent.

Mais ce n'est pas fini. Une fois que ce test est en cours d'exécution et en rouge (démontrant l'erreur dans le code), prenez le temps de comprendre ce qui ne va pas (vous devez le faire, en tout cas). Mais ne le corrige pas encore. Une fois que vous avez isolé ce que vous pensez être le problème - écrivez une unitétest qui démontre ce problème. Maintenant, vous avez quelque chose avec lequel vous pouvez travailler (et, ce n'est pas un hasard, vous devrez peut-être refaçonner un peu plus vers une testabilité encore plus grande). Corrigez le bug. Regardez le test unitaire réussir. Peut-être étoffez-le avec quelques cas de bord; obtenez cette unité - celle qui vous a juste coûté deux semaines - solide et propre et bien testée. Maintenant, lancez le test de régression et regardez-le passer (bien sûr, si ce n'est pas le cas, vous avez encore des recherches et du travail au niveau de l'unité à faire - répétez jusqu'à ce qu'il passe également). Vérifiez tout. Qu'avez-vous? Tests de régression pour le code précédemment défaillant. Tests unitaires pour le code précédemment défaillant. Code de travail qui échouait. Code mieux conçu, car il est désormais plus testable qu'il ne l'était. Meilleure confiance dans votre base de code,

Ce n'est pas du TDD "pur". Mais il démontre les résultats rapidement et améliore la qualité de votre code au fil du temps. Les résultats vous aideront à obtenir l'adhésion de la direction.

Dans mon entreprise, je suis juste allé avec la méthode "seulement un grognement" de JoelOnSoftware et j'ai commencé à écrire des tests unitaires chaque fois que j'aurais normalement piraté une sorte d'application console jetable. J'ai commencé à faire les choses beaucoup plus rapidement avec des versions plus stables et je me suis fait remarquer. Lorsqu'on m'a demandé ce que je faisais, j'ai expliqué que j'avais commencé à utiliser TDD et à écrire des tests unitaires chaque fois que je modifiais l'ancien code ou écrivais un nouveau code. Mes collègues développeurs ont commencé à devenir curieux et à utiliser eux-mêmes les tests unitaires intégrés. Je ne pense pas qu'il y ait un bon argument pour écrire des tests pour le code hérité de travail, mais si vous pouvez démontrer que l'écriture de tests automatisés est plus rapide et plus pratique que l'écriture de spaghettis de piratage de console, alors les développeurs intelligents suivront.Les autres avantages qui se traduisent par des logiciels de meilleure qualité seront également présents, mais la clé pour obtenir la connexion des développeurs est de montrer que cela leur facilite la vie. En ce qui concerne la connexion des entreprises, le fait qu'il se traduira par de meilleurs logiciels et prendra probablement moins de temps à expédier qu'auparavant devrait être plus que suffisant pour les convaincre.

Tout d'abord, votre attitude et votre sens de la sincérité pour la valeur ajoutée de qualité à l'argent du client doivent être appréciés. Et voici mes réflexions sur la façon de convaincre votre manager et votre client:

• Collectez les métriques des bogues que vous corrigiez, disons au cours des 6 derniers mois, ainsi que le temps minimum, moyen et maximum qu'il vous a fallu pour corriger un bogue.
• Pour tous les bogues que vous avez corrigés ou dans lesquels vous avez un contexte, essayez d'écrire des tests unitaires couvrant ces domaines.
• Pour les bogues sur lesquels vous travaillez et ceux sur lesquels vous allez travailler, essayez d'écrire des tests unitaires autour de ces zones avant même d'apporter des modifications. Ensuite, écrivez du code pour comprendre la cause et la corriger. Voyez si cela casse l'un de vos cas de test existants. Si oui, expliquez et aidez vos pairs à comprendre l'importance des tests unitaires.
• Une fois que tous les développeurs ont compris l'importance des tests unitaires, demandez-leur de continuer à faire ce que vous faites depuis tant de jours / semaines.
• Au fil du temps, la productivité des équipes devrait s'améliorer dans la mesure où votre manager et vos clients seraient surpris du taux d'amélioration de la productivité et de la qualité du code. C'est un peu long, mais ça vaut le coup d'essayer.

Il y a une autre façon, et c'est d'essayer de rejoindre votre manager pour assister aux conférences Agile qui se produisent autour. Cela vaut certainement la peine d'y assister.

Si vous pensez que rien ne fonctionne, alors passez à autre chose ... rejoignez l'endroit qui vous convient. Franchement, c'est ce que j'ai fait. Quand tout a échoué, je suis parti;)

Et savoir ce que Unit teste après avoir écrit le code n'est pas vraiment TDD, mais cela peut toujours être la première étape. Ça va si bien ici au moins.

Je vous souhaite bonne chance et succès!