Un collègue ne veut pas utiliser les tests unitaires «car il s'agit plus de coder»

Un collègue ne veut pas utiliser les tests unitaires et opte plutôt pour un test rapide, le passe aux utilisateurs, et si tout va bien, il est publié en direct. Inutile de dire que certains bugs sont résolus.

J'ai mentionné que nous devrions penser à utiliser des tests unitaires - mais elle était tout à fait contre quand on a réalisé que plus de code devrait être écrit. Cela me laisse dans la position de modifier quelque chose et de ne pas être sûr que la sortie est la même, d'autant plus que son code est du spaghetti et j'essaie de le refactoriser quand j'en ai l'occasion.

Alors, quelle est la meilleure voie à suivre pour moi?

Elle ne connaît pas les avantages des tests unitaires et c'est ce que vous devez changer:

• Sa conscience.

Vous devrez lui prouver que cela améliorera son travail et pas seulement le vôtre. Ce sera difficile, elle essaiera probablement de se concentrer sur tous les aspects négatifs qu'elle pourrait trouver si elle a peur du changement.

Vous pouvez essayer de discuter avec elle de tous les avantages et d'écouter tous ses contre-arguments. Attendez qu'elle ait fini de parler avant de commencer à vous parler.

Pour vous préparer, vous devriez regarder sur P.SE ou Google pour toutes les choses que la direction ou les développeurs s'inquiètent des tests unitaires et compiler les réponses que vous utiliserez lors de vos discussions avec votre collègue.

Il suffit de l'écouter et de lui prouver que cela améliorera son travail vous aidera beaucoup. Vous prouvez que vous êtes préoccupé par son opinion et vous lui fournissez toutes les données dont elle a besoin pour analyser la situation et éventuellement changer d'avis.

Écrivez un test unitaire (ne lui dites pas)

Attendez que la chose se brise, laissez-la faire des tests manuels pendant deux jours, puis retirez vos tests unitaires et trouvez un bug en trois secondes.

À l'abri ...

L'automatisation de tâches autrement manuelles devrait plaire à tout programmeur.

Elle n'écrit donc pas plus de code, elle en fait moins manuellement.

(L'un des) points des tests automatisés est la répétabilité . Si vous faites un test rapide à la main, vous pouvez le faire plus rapidement que d'écrire la même chose qu'un test unitaire (pour un débutant de test unitaire au moins - toute personne expérimentée dans le test unitaire peut produire des tests assez rapidement).

Mais que se passe-t-il lorsque demain, ou la semaine prochaine, un petit (ou gros ...) changement est apporté au code? Votre collègue serait-il heureux de répéter les mêmes tests manuels encore et encore après chaque modification, pour vous assurer que rien n'est cassé? Ou préférerait-elle "coder et prier"?

Plus le code est modifié, plus les tests unitaires remboursent votre investissement initial . Il ne faut pas longtemps pour être positif, même sans que les tests ne détectent réellement de bugs. Mais ils le font régulièrement aussi - à ce stade, ils deviennent inestimables. Et une fois que quelqu'un éprouve ce sentiment de sécurité et de confiance dans son code qu'apporte un test unitaire réussi, il n'y a généralement pas de retour en arrière.

Si elle est en quelque sorte convaincue mais a peur de s'aventurer dans le nouveau domaine, offrez-lui une session de programmation en binôme pour écrire ses premiers tests unitaires ensemble . Choisissez une classe qui n'est pas trop difficile à tester mais suffisamment complexe pour que cela vaille la peine d'être testé.

Cependant, si elle n'est pas convaincue, vous devrez peut-être continuer à collecter des faits concrets . Ces faits peuvent être

• taux de défauts dans le code écrit par vous par rapport au sien
• écrire un ensemble de tests unitaires par rapport à son code et documenter les bogues trouvés.

Recueillez certaines de ces données, puis montrez-lui poliment les résultats. Si cela ne suffit toujours pas pour la convaincre, vous devrez peut-être discuter du problème et partager les preuves collectées avec la direction. Cela ne devrait être que votre dernier recours, mais parfois il n'y a pas d'autre moyen.

Écrivez une couverture de test de base pour les pires morceaux de son code, réduisez-la en fonction de ces tests, puis montrez à la direction que les tests unitaires sur les versions continues amélioreront la productivité. Les changements deviennent plus faciles lorsqu'ils sont mandatés par un employeur plutôt qu'évangélisés par un seul développeur.

Je ne sais pas comment l'exprimer correctement, mais: si vous refactorisez son code "quand vous en avez l'occasion" ... eh bien, elle pense probablement que vous êtes un peu une putain de vous impliquer dans "son entreprise" , est donc moins susceptible de vous écouter avec un esprit ouvert. D'après mon expérience, les gens s'attachent à ce qu'ils ont fait - même quand ce n'est pas très bon.

Pour jouer l'avocat des démons: elle a raison. Je le mets généralement comme:

Les tests automatiques résolvent les problèmes de trop de code avec encore plus de code.

Raisonnement:

• étude sur la corrélation du taux de défaut et des métriques OO , résultat global : "Après avoir contrôlé la taille [de la classe], aucune des métriques que nous avons étudiées n'était plus associée à la propension aux défauts" . (L'étude examine la taille des classes. Cet effet s'étend-il à la taille de la base de code? Probablement. À mon avis )
• Empiriquement, les grands projets ont tendance à avancer lentement. "5K lignes pendant la nuit dans un nouveau projet" contre "10 lignes / jour sur un grand". Cela indique-t-il une "résistance" au changement augmentant avec la taille de la base de code?
• Nous proclamons toujours "il n'y a pas de meilleur langage, cela dépend du problème". Une exigence clé consiste à modéliser facilement les entités et opérations problématiques dans la langue de leur choix. Cela ne signifie- t-il pas que choisir une langue dans laquelle exprimer votre problème est plus élaboré est pire , et cela ne correspond-il pas encore à la taille finale de la base de code?

Maintenant, il y a quelques arguments pour tirer contre cela facilement. Permettez-moi d'aborder celles auxquelles je peux penser:

• taille vs simplicité: Bien sûr, il est possible de rendre le code plus court et pire. Cependant, ce n'est qu'un problème lorsque l'on compare des bases de code avec différents ratios de concision-simplicité, pour la discussion on peut supposer que nous pourrions en quelque sorte contrôler ce facteur.

• Les tests unitaires vous poussent à réduire les dépendances, et je conviens empiriquement que la réduction des dépendances peut atténuer les problèmes de taille de code (dans le sens où, avec deux bases de code de taille similaire, celle avec plus d'interdépendances est pire). Cependant , tout en réduisant les dépendances entre les unités de code de production, il introduit un couplage entre le test et l'unité elle-même.

TL; DR: Je ne dis pas que les tests unitaires sont mauvais; Je demande: y a-t-il un seuil de rentabilité où les tests font mal qui est corrélé à la quantité de code?

Je pense que vous êtes dans une position difficile. J'ai fait partie d'une équipe où les gens n'écrivaient pas de tests unitaires, ou pire, d'horribles tests unitaires non maintenables. Mais tout le monde était conscient du fait que les tests unitaires sont bons.

Il a donc été difficile de faire en sorte que la suite de tests unitaires de l'équipe soit de bonne qualité. Toujours à l'affût des améliorations possibles, en communiquant des idées, en partageant des expériences.

D'un autre côté, vous avez un développeur qui n'a même pas réalisé l'avantage. Et puis code aussi le code spaghetti. Je suppose que l'une des raisons les plus importantes dans ce cas particulier est le fait que l'écriture de bons tests unitaires impose une conception faiblement couplée. Ainsi, l'amener à écrire le test pourrait, espérons-le, à long terme également améliorer le "vrai" code.

Mais je pense qu'au final, c'est une décision d'équipe (je ne sais pas combien vous êtes dans l'équipe?). Si l'équipe peut parvenir à un consensus sur le fait qu'il devrait y avoir une suite de tests unitaires bien couvrant, alors tout le monde doit se conformer, partager des expériences et laisser votre équipe se renforcer ensemble.

Si l'équipe ne parvient cependant pas à un consensus sur le fait que vous devriez écrire des tests unitaires, alors je vous suggère de trouver une autre équipe de développement avec qui travailler;)

C'est elle le patron?

Si c'est le cas ... vous êtes un peu coincé à moins que vous ne puissiez la convaincre des avantages qui sont fondamentalement du type "une once de prévention vaut une livre de guérison". Les bugs passent. TDD aide à atténuer cela en créant une sortie cohérente.

N'est-elle pas la patronne?

Quelles sont les normes de codage dans lesquelles vous travaillez? Pourquoi est-elle autorisée à cracher du code de spaghetti? Présentez une analyse de rentabilisation au patron en disant "Nous passerons BEAUCOUP moins de temps sur les bogues si nous passons un peu plus de temps sur TDD". Convainquez quelqu'un qui peut appliquer le changement avec une analyse de rentabilisation.

Documentez les cas où TDD aurait pu gagner du temps et $$ MONEY $$.

Ce bug s'est présenté. Il aurait été capturé avant d'être mis en ligne. Passer 2 heures de prévention nous aurait fait économiser 10 heures de cure. C'est arrivé ici et ici et ici. Ces 10 heures de travail qui auraient permis à l'entreprise d'économiser 30 heures de travail. C'est autant d'argent.

Cela me laisse dans la position de modifier quelque chose

Pourquoi?

Ils ont créé le problème. Ils devraient le résoudre.

Quel gestionnaire permet que cela se produise? Pourquoi le code buggy de quelqu'un d'autre est-il maintenant votre problème?

Vous avez un collègue et un gestionnaire qui font tous les deux cela. Et en nettoyant leur gâchis, vous êtes un participant volontaire et actif.

Rien ne changera s'ils ne ressentent pas la douleur de mauvaise qualité.

Elle a tout à fait raison, les tests unitaires sont "plus de code".

Cependant, c'est simplement plus de code qui doit être écrit pour s'assurer que le programme fonctionne comme il le devrait (encore et encore). Ce n'est pas du temps perdu. C'est autant une partie du système que ses composants de base.

Défiez-la sur:

1. Que se passe-t-il si quelqu'un qui n'est pas familier avec le code change quelque chose.
2. Que se passe-t-il si quelqu'un qui n'a pas d'expérience change quelque chose.
3. Le coût de la maintenance d'un système ne se mesure pas en temps de création. C'est une proposition à plus long terme. Pensez au coût total de possession.
4. Son estimation (si cela était nécessaire avant le début du codage) devrait inclure l'obligation d'écrire des tests unitaires. Les hommes d'affaires ne créent pas d'exigences qui nécessitent directement des tests unitaires, mais ils ont une exigence implicite de qualité et exigent que les changements futurs ne soient pas criblés de bogues ou que le même programmeur change sa source.

Parlant comme celui qui fait actuellement du code de production, suivi par des tests unitaires plutôt que TDD, ce qui ne semble pas être un bon ajustement à ma place actuelle (j'ai fait TDD sur certains projets, mais le vois juste comme un autre outil dans le vieux sac, pas une balle d'argent) ...

Cela peut être difficile à vendre. Je n'ai toujours pas été en mesure de vendre mes collègues sur des tests unitaires. Je sais que j'ai tendance à faire beaucoup plus d'erreurs dans mon code de test unitaire que dans mon code de production. Donc, c'est un peu frustrant de devoir passer autant de temps à fixer le code de test unitaire ... Cependant, c'est une bonne assurance lorsque le code est modifié. Excellent moyen de tester automatiquement les conditions de bord.

Montrez-lui combien les tests unitaires aident en créant vous-même des tests unitaires.

Comme l'a dit un jour saint François, "Prêchez toujours. Si nécessaire, utilisez des mots."

Si elle voit que votre code utilise des tests unitaires et que vous pouvez résoudre les bogues plus rapidement avec des tests unitaires, cela peut changer d'avis. Mais ce n'est peut-être pas le cas.

Peu importe le résultat, elle ne vous voit pas comme lui poussant quelque chose que vous n'êtes pas prêt à faire. C'est ce que vous devez changer, la perception que vous ne montrez pas l'exemple.