Je veux présenter le concept des tests unitaires (et des tests en général) à mes collègues; en ce moment, il n'y a aucun test du tout et les choses sont testées en effectuant les tâches via l'interface utilisateur pour voir le résultat souhaité. Comme vous pouvez l'imaginer, le code est très étroitement couplé à l'implémentation exacte - ce qui entraîne même que le code qui devrait être dans une classe et réutilisé dans le système soit copié et collé entre les méthodes.

En raison des exigences modifiées, on m'a demandé de modifier un module que j'ai écrit précédemment et qui est assez peu couplé (pas autant que je le souhaiterais, mais du mieux que je peux obtenir sans avoir à introduire beaucoup d'autres concepts). J'ai décidé d'inclure une suite de tests unitaires avec mon code révisé pour "prouver" qu'il fonctionne comme prévu et montrer comment les tests fonctionnent; Je ne suis pas en train de suivre le vrai TDD car une partie du code est déjà écrit mais j'espère suivre certains concepts TDD pour le nouveau code que je devrai créer.

Maintenant, inévitablement, je suis sûr qu'on me demandera pourquoi cela me prend plus d'un jour ou deux pour écrire le code, car des parties de ce avec quoi je vais interagir existent déjà dans le système (bien que sans aucun test et très étroitement couplé), et quand je vérifierai le code, on me demandera ce qu'est ce projet "Tests". Je peux expliquer les bases des tests, mais je ne peux pas expliquer les avantages réels d'une manière que les autres comprendraient (car ils pensent que les tests vous obligent à exécuter l'application vous-même, car souvent l'interface utilisateur réelle est importante pour déterminer si la fonctionnalité "fonctionne" " ou pas). Ils ne comprennent pas l'idée d'un couplage lâche (clairement évident par le fait que rien n'est lâchement couplé; il n'y a même pas d'interfaces en dehors du code que j'ai écrit), donc essayer de l'utiliser comme un avantage me gagnerait probablement un "Huh?" genre de look, et encore une fois, je ne peux pas être aussi lâche que je le voudrais sans avoir à retravailler plusieurs modules existants et probablement introduire une sorte de conteneur IoC, qui serait considéré comme une perte de temps et non une "programmation".

Quelqu'un a-t-il des suggestions sur la façon dont je peux pointer vers ce code et dire "Nous devrions commencer à créer des tests unitaires" sans se présenter comme condescendant (par exemple, "L'écriture de tests vous oblige à écrire du bon code.", Ce qui serait probablement considéré comme du code sauf que la mienne est mauvaise ) ou sans donner l'impression que c'est une perte de temps qui n'ajoute aucune valeur réelle?

Je veux présenter le concept des tests unitaires (et des tests en général) à mes collègues

Je pense qu'il vaudrait peut-être mieux partir du côté pratique et non conceptuel. Bien sûr, si vous trouvez au cours d'une discussion informelle que vos collègues et / ou la direction sont intéressés à entendre parler des tests unitaires, tant mieux - alors vous pouvez rechercher sur Google des expériences / preuves concrètes sur le Web, organiser une brève formation, etc. Cependant, d'après ce que vous décrivez, il semble que vos coéquipiers ne soient pas très ouverts à cette étrange nouvelle idée.

Dans une telle situation, je commençais juste à écrire mes petits tests unitaires sans essayer d'expliquer trop à quiconque d'abord. Ajoutez-en deux chaque fois que je change de code, sans essayer de couvrir complètement tout le code (ce qui prendrait un temps excessif). Idéalement, si je parviens à trouver un juste équilibre, au moment où ils remarquent que j'écris des tests unitaires, j'ai peut-être déjà une suite de tests substantielle et quelques résultats concrets à montrer (comme "avec ce cas de test, j'ai réussi à attraper un bug introduite par le changement de la semaine dernière, qui aurait autrement glissé vers l'AQ / production "). Cela prouvera la valeur des tests à tout développeur sérieux.

Après cela, je suis bien placé pour commencer à expliquer les avantages à long terme des tests unitaires, comme

• cela prouve que le code fonctionne - à tout moment, n'importe où, instantanément et automatiquement, ce qui à son tour
• donne confiance au refactor, ce qui se traduit par une conception améliorée et une meilleure maintenabilité,
• et si quelque chose se casse, les tests unitaires vous donnent un retour (presque) instantané, par opposition à une latence de plusieurs jours ou semaines si le bogue est détecté par un service d'assurance qualité distinct. Ce qui vous permet généralement de corriger le bogue en quelques secondes, au lieu de déboguer pendant des heures / jours, dans du code qui a depuis longtemps disparu de votre mémoire à court terme.

Voir aussi ce fil connexe: Tests unitaires automatisés, tests d'intégration ou tests d'acceptation .

Et une précédente de SO: Qu'est-ce qu'un test unitaire?

Re-factoriser sans peur

Sous un angle légèrement différent, TDD vous permet de «re-factoriser sans crainte», et c'est un avantage clé que vous pouvez vendre à votre équipe. Cela empêche les développeurs de se dire:

• "Je ne veux pas toucher à ce code car j'ai peur de le casser"
• "Je ne veux pas écrire de nouvelles fonctionnalités sur pof ce code car je ne sais pas comment cela fonctionne"
• "Secrètement, j'ai peur de ce code"

Je pourrais en dire plus, mais c'est un terrain bien couvert comme Oncle Bob sur TDD et Martin Fowler sur TDD .

Dépendances

Oh, je vais ajouter une chose. Il leur montrera comment TDD impose une bonne conception qui vous permet de gérer proprement les dépendances.

Bob: "Oh c% ^ p! Les patrons nous ont tous forcés à utiliser MS SQL Server 2008" Jane: "C'est OK, les dégâts sont minimisés parce que nous DI notre source de données et nos classes DAO, je suis si heureux que TDD ait encouragé nous sur cette voie. "

Tout en travaillant sur du code source qui n'a pas de tests automatisés, nous devons travailler avec beaucoup de soin et avons besoin de plus de révisions pour rester en confiance que le type de changements que nous apportons ne casse aucune des fonctionnalités existantes.

Lorsque nous avons de bons cas de test automatisés, les conséquences seront un développement plus rapide, sûr et sans peur (cela peut être la correction de bogues, l'amélioration ou la refactorisation).

Faire le calcul

• t _mt = le temps nécessaire pour tester manuellement tout ce que vous pourriez vraisemblablement affecter
• t _wt = le temps nécessaire pour écrire les tests

• k = le nombre de fois que vous devrez probablement tout tester avant de publier le nouveau code

  si (t _wt <t _mt ) ou (t _wt <(k * t _mt )) alors c'est une évidence: l'écriture des tests accélérera le développement.

sinon, regardez le rapport (t _wt / (k * t _mt )). S'il s'agit d'un très grand nombre, attendez une autre opportunité; justifier autrement par des avantages liés aux tests de régression.

Remarque: je suggère à ce stade de ne tester que les fonctionnalités, pas les unités - beaucoup plus faciles à justifier et à comprendre, et sans doute moins de travail avec une valeur plus élevée que les simples tests unitaires lors de la refactorisation.

Remarque 2: le temps nécessaire pour exécuter les tests n'a pas d'importance , car ils sont automatisés. Vous pouvez faire quelque chose d'autre de productif pendant l'exécution des tests, à moins que les tests ne prennent trop de temps pour vous faire manquer la date limite. Ce qui est rare.

Une suggestion si vous êtes un magasin Microsoft: trouver de la documentation sur MSDN qui recommande des tests unitaires ou couping lâche comme une meilleure pratique (je suis sûr qu'il ya plusieurs instances de ce ) et point s'il y a des conflits.

Cela peut sembler une façon grossière de faire les choses, mais j'ai constaté que l'utilisation du terme «meilleure pratique» vous prendra beaucoup de temps, en particulier avec la direction.

Comme je le recommande toujours, si vous connaissez une bonne pratique, la meilleure façon de l'introduire doucement dans votre environnement serait bien sûr de commencer à le faire vous-même, puis quelque part en cours de route, certains de vos collègues verront les avantages et ramasser.

Le mot-clé ici est évolution, pas révolution.