TDD / Teste-t-il trop de frais généraux / de maintenance?

Vous l'avez donc entendu à plusieurs reprises de la part de ceux qui ne comprennent pas vraiment les valeurs des tests. Pour commencer, je suis un adepte de l'agilité et des tests ...

J'ai récemment eu une discussion sur la réalisation de TDD sur une réécriture de produit où l'équipe actuelle ne pratique pas les tests unitaires à aucun niveau, et je n'ai probablement jamais entendu parler de la technique d'injection de dépendance ou des modèles de test / conception, etc. (nous n'obtiendrons même pas sur pour nettoyer le code).

Maintenant, je suis entièrement responsable de la réécriture de ce produit et on me dit que l'essayer à la manière de TDD, en fera simplement un cauchemar de maintenance et impossible pour l'équipe. De plus, comme il s'agit d'une application frontale (non basée sur le Web), l'ajout de tests est inutile, car le dynamisme de l'entreprise change (par changements, ils signifient des améliorations bien sûr), les tests deviendront obsolètes, d'autres développeurs qui viendront à le projet à l'avenir ne les maintiendra pas et deviendra plus un fardeau pour eux à réparer, etc.

Je peux comprendre que TDD dans une équipe qui n'a actuellement aucune expérience de test ne semble pas bon, mais mon argument dans ce cas est que je peux enseigner ma pratique à ceux qui m'entourent, mais plus encore, je sais que TDD fait MIEUX Logiciel. Même si je devais produire le logiciel en utilisant TDD et jeter tous les tests pour le remettre à une équipe de maintenance, ce serait sûrement une meilleure approche que de ne pas utiliser TDD du tout?

J'ai été abattu car j'ai mentionné faire du TDD sur la plupart des projets pour une équipe qui n'en avait jamais entendu parler. La pensée des "interfaces" et des constructeurs DI étranges les effraie ...

Quelqu'un peut-il m'aider s'il vous plaît dans ce qui est normalement une très courte conversation d'essayer de vendre TDD et mon approche aux gens? J'ai généralement une très courte fenêtre de discussion avant de tomber à genoux devant l'entreprise / l'équipe.

l'essayer à la manière de TDD, en fera simplement un cauchemar de maintenance et impossible pour l'équipe à maintenir.

Vous ne pouvez pas gagner cet argument. Ils inventent ça. Malheureusement, vous n'avez pas non plus de faits réels. Tout exemple que vous fournissez peut être contesté.

La seule façon de faire valoir ce point est d'avoir du code qui est moins coûteux à maintenir.

De plus, comme il s'agit d'une application frontale (non basée sur le Web), l'ajout de tests est inutile,

Tout le monde le dit. Cela peut aussi être partiellement vrai. Si l'application est raisonnablement bien conçue, le front-end fait très peu.

Si l'application est mal conçue, cependant, le front-end en fait trop et est difficile à tester. Il s'agit d'un problème de conception, pas d'un problème de test.

au fur et à mesure que la dynamique commerciale change (par des changements, ils signifient des améliorations bien sûr), les tests deviendront obsolètes, d'autres développeurs qui viendront dans le projet à l'avenir ne les maintiendront pas et deviendront plus un fardeau pour eux à réparer, etc.

C'est le même argument que ci-dessus.

Vous ne pouvez pas gagner l'argument. Alors ne discutez pas.

"Je suis entièrement responsable de la réécriture de ce produit"

Dans ce cas,

1. Ajoutez quand même des tests. Mais ajoutez des tests au fur et à mesure, progressivement. Ne passez pas longtemps à faire passer des tests en premier. Convertissez un peu. Testez un peu. Convertissez un peu plus. Testez un peu plus.

2. Utilisez ces tests jusqu'à ce que quelqu'un comprenne que le test fonctionne et demande pourquoi les choses vont si bien.

J'ai eu le même argument sur une réécriture (de C ++ à Java) et j'ai simplement utilisé les tests même s'ils m'ont dit de ne pas le faire.

Je me développais très rapidement. J'ai demandé des exemples concrets de résultats corrects, qu'ils ont envoyés dans des feuilles de calcul. J'ai transformé les feuilles de calcul en unittest.TestCase (sans leur dire) et les utilise pour tester.

Quand étaient dans les tests d'acceptation des utilisateurs - et des erreurs ont été trouvées - je viens de demander que les feuilles de calcul avec les exemples soient examinées, corrigées et développées pour couvrir les problèmes rencontrés lors du test d'acceptation. J'ai transformé les feuilles de calcul corrigées en unittest.TestCase (sans leur dire) et les utilise pour tester.

Personne n'a besoin de savoir en détail pourquoi vous réussissez.

Soyez juste réussi.

Vous ne pouvez convaincre ces personnes (le cas échéant) que du point de vue pratique, démontrant la valeur du TDD dans la vie réelle. Par exemple, en prenant un bug récent comme exemple, et en montrant comment construire un test unitaire qui garantit à 100% que ce bug n'apparaîtra plus jamais. Et puis, bien sûr, écrivez une douzaine de tests unitaires supplémentaires pour empêcher toute la classe de bogues similaires d'apparaître (et qui sait, peut-être même en train de découvrir quelques bogues dormants supplémentaires dans le code).

Si cela ne fonctionne pas à court terme, vous devez y travailler plus longtemps, simplement en effectuant TDD et en écrivant des tests unitaires avec diligence sur vos propres tâches. Ensuite, compilez quelques statistiques simples au bout de six mois environ (si cela est possible dans votre environnement) pour comparer les taux de bogues dans le code / les tâches accomplies par différents développeurs (anonimyzed pour éviter d'aliéner vos coéquipiers). Si vous pouvez faire remarquer qu'il y avait beaucoup moins de bogues trouvés dans votre code que dans d'autres, vous pourriez avoir un point fort à vendre à la fois à la direction et aux autres développeurs.

Vous devez être pratique sur ces choses, TDD est une bonne chose à avoir en théorie, mais à moins que vous ne mettiez à jour vos tests pour tout ce qui est ajouté, cela ne sert à rien - personne ne veut exécuter un test qui signale des pannes code quand c'est le test qui n'a pas été mis à jour! En conséquence, cela peut facilement être trop coûteux - vous ne serez pas le seul développeur à travailler sur ce code.

Le client a une équipe de test .. eh bien, il n'y a aucun problème à déplacer la charge de test du développeur vers les testeurs - c'est pour cela qu'ils sont là après tout, et s'ils trouvent des bugs à travers leurs tests (peut-être qu'ils ont beaucoup de outils de tests automatisés), il est inutile d’écrire des tests unitaires à votre niveau. Il faudra un peu plus de temps pour trouver les bogues, mais ils trouveront ces bogues "d'intégration" embêtants que vos tests n'auraient pas exercés.

Il y a de fortes chances pour qu'elles ne se soucient pas des tests unitaires.

Enfin, TDD est une chose nouvelle, quand j'étais enfant, nous n'avions jamais testé et nous avons écrit du code qui fonctionnait. Les tests unitaires font que certaines personnes se sentent chaleureuses et floues, mais ce n'est absolument pas une exigence pour un code correct.

PS. Je vois une autre de vos questions où vous critiquez les couches d'abstraction, et ici vous critiquez le manque de constructeurs DI! Faites votre choix :)

Puisque tout change si rapidement que vous le dites, expliquez-leur qu'il sera utilisé pour les tests de régression. Ce qui permettra d'économiser beaucoup de maux de tête lorsque de nouveaux bogues sont introduits car quelqu'un a rompu une ligne de code écrite il y a 10 ans pour résoudre un problème qui se produit 1 sur 10 000 000 d'exécutions d'une fonction spécifique qui n'est appelée que si l'horloge système est allumée. le client a une différence supérieure à 3 minutes par rapport à l'horloge système du serveur. Demandez-leur simplement combien de clients ils peuvent se permettre de perdre à cause d'un logiciel buggy.

Soulignez que la découverte d'un bogue pendant le développement coûte X, pendant les tests 10X et après le déploiement 100X. Voyez s'ils vous permettront au moins de mener un test pilote où vous implémentez TDD dans un module spécifique, puis effectuez des comparaisons avec d'autres modules au fur et à mesure qu'ils sont développés, testés, déployés et pris en charge. Avec des données adéquates, vous devriez pouvoir démontrer comment moins d'efforts ont été utilisés pour produire du code dans le module TDD. Bonne chance.

Oui, le maintien des tests est un fardeau. Les mettre à jour, mettre à jour vos données de test: tout cela vous fait perdre du temps.

L'alternative - tester manuellement des choses, refixer des bogues qui régressent, ne pas pouvoir dire en quelques secondes que votre code fonctionne - coûte beaucoup plus cher.

Eh bien, le test est un fardeau, mais c'est un bon fardeau à porter. Il est préférable de faire un travail en amont, ce qui permettrait de gagner beaucoup de temps en cas de problème de production ou lors de la migration. Je voudrai toujours passer un test même si c'est peu de fardeau, mais je veux porter ce fardeau.