Je n'écris pas de tests. Suis-je stupide ?

Question

J'ai lu un peu sur les tests unitaires et le TDD, et je n'ai jamais sérieusement envisagé d'écrire des tests de façon aussi précise. Il est vrai que je ne travaille pas sur des projets qui sont ridiculement énormes. Si je ne construis que de petites applications, suis-je stupide de ne pas écrire de tests ?

Modifier : Pour clarifier, quand je dis "petites applications", je veux dire des applications qui ne vont pas contrôler la vie d'une personne et/ou ses biens. Je construis généralement des choses qui sont censées faciliter la vie des gens et les rendre plus efficaces.

Answer 1

Je ferais au moins un essai. J'ai décidé de l'essayer sur un projet secondaire. Dès les premiers jours, j'avais déjà sauvé ma peau à plusieurs reprises lorsque mes modifications de code avaient provoqué des "effets secondaires" que mes tests unitaires avaient détectés.

J'ai réalisé que je prenais moins de temps pour déboguer et "tester" mon code en l'exécutant et en le testant manuellement. Maintenant, sur ce projet, je peux changer le code et exécuter les tests unitaires et savoir que c'est bon au lieu de lancer l'application et de taper mon ensemble de valeurs pour tout tester visuellement à chaque fois que je fais un changement.

Answer 2

Les gens intelligents font des choses stupides tout le temps. Vous n'êtes pas obligé d'utiliser le TDD complet, mais ne pas écrire de tests automatisés alors que tout le monde le considère comme la meilleure pratique est certainement un comportement stupide.

Personnellement, je dirais que la seule justification pour ne pas écrire de tests est lorsque la qualité compte beaucoup moins que l'obtention d'un résultat rapide (même si c'est à moitié fait) ou lorsque le code ne restera pas longtemps en place. Des scripts à jeter, des prototypes exploratoires, une nouvelle fonctionnalité avec une date limite demain fixée par un client impatient mais tolérant aux bogues. Ce genre de choses.

Pour tout le reste, les tests automatisés vous permettent d'obtenir une meilleure qualité avec moins de travail.

Answer 3

Mon expérience :

• Écriture d'une application critique de 75 000 lignes.
• Depuis le jour où nous avons mis ce programme en production, il a fait ce qu'il devait faire. avec une fiabilité à toute épreuve.

Avertissement : je programme depuis que je suis enfant, je suis donc bon dans mon travail - mais même moi, j'ai été surpris par l'effet spectaculaire de quelques règles de test simples, qui ont permis à l'application de fonctionner de manière aussi fiable qu'une Mercedes haut de gamme.

La forme de test qui a fonctionné pour moi :

• Je n'ai pas fait ce que certains praticiens ont recommandé, à savoir "tester d'abord, coder ensuite". J'ai plutôt adopté l'approche consistant à intégrer autant de tests que possible dans le projet, avant ou après l'écriture du code. Pour certaines méthodes, il était plus facile d'écrire la méthode d'abord, puis les tests. Pour d'autres méthodes, il était plus facile d'écrire les tests d'abord, puis la méthode.
• Je n'ai pas utilisé de frameworks de tests unitaires, j'ai plutôt intégré les tests dans la structure même du programme, comme décrit dans les autres points. Le seul framework que j'ai utilisé est un framework de journalisation tiers pour les avertissements et les erreurs générés. Je ne nommerai pas le cadre commercial que j'ai utilisé, afin de garder cet article neutre, et tout cadre de journalisation gratuit ou commercial fera l'affaire. Je recommande tout cadre de journalisation qui vous permet d'afficher le journal, puis de le filtrer selon certains critères, car cela est très utile lorsque vous recherchez une activité suspecte dans les grands journaux.
• Utilisé tests au niveau des classes : chaque classe avait une méthode qui testait toutes les autres méthodes de la classe. Certaines méthodes avaient une méthode "sœur" qui était responsable de l'exécution des tests sur ladite méthode.
• Utilisé tests au niveau des applications J'ai écrit beaucoup de tests unitaires pour introduire des données réelles dans le programme, puis vérifier que les données qui revenaient étaient conformes aux attentes (généralement, il s'agissait d'un simple contrôle des limites).
• Utilisé test de niveau ligne par ligne : chaque fois que je connaissais la plage de valeurs attendues dans une variable ou un tableau, j'enregistrais un avertissement silencieux si les données sortaient de cette plage. En d'autres termes, les tests unitaires étaient intégrés dans la structure même du code. Ces tests pouvaient être désactivés en mode Release, mais j'ai trouvé que cela n'affectait pas beaucoup la vitesse de l'application finale, alors je les ai laissés activés.

De tous les tests que j'ai ajoutés, j'ai trouvé que les test de niveau ligne par ligne a eu l'effet le plus positif sur la fiabilité de l'application dans son ensemble. Il est étonnant de constater qu'une simple règle telle que "enregistrer un message d'avertissement silencieux si le contenu d'une variable n'est pas ce que vous attendez" peut avoir un effet aussi profond sur la fiabilité de l'application dans son ensemble.

L'avantage de cette approche est qu'elle a permis de raccourcir le cycle de développement. Certes, de nombreuses erreurs et avertissements ont été enregistrés au début, mais une fois ceux-ci corrigés, le résultat final était étonnamment fiable. Cette approche a rendu le programme beaucoup plus robuste aux changements et au remaniement. J'ai perdu le compte du nombre de fois où j'ai modifié quelque chose que je pensais être mineur, ce qui a fait apparaître un avertissement, lequel m'a permis de corriger une erreur qui aurait pu se retrouver en production. La phase habituelle de post-production, qui consiste à passer des mois à trouver des bogues difficiles à localiser, a été pratiquement éliminée. C'était extrêmement important, car il s'agissait d'une application critique avec beaucoup d'enjeux en cas de problème.

La forme de test que j'ai utilisée n'est pas une solution miracle, mais elle vous facilitera la vie (et celle de vos patrons).

En résumé, la seule fois où je n'utiliserais pas les tests, c'est si j'étais une sorte de masochiste travaillant pour mon pire ennemi et que je voulais faire de nos vies un enfer.

Answer 4

Kent Beck a posé une question similaire dans son dernier blog. entrée mais il déclare qu'il ne refuse de tester que les choses dont il ne sait pas si elles seront un jour un logiciel à long terme (maintenabilité, etc.) et dont le test est très difficile à écrire.

Answer 5

En lisant vos modifications, je dirais que vos objectifs sont de faciliter la vie des gens, ce qui nécessite de connaître leurs besoins et de les satisfaire. Ceux-ci évoluent, et comme ils le font, vous devez modifier votre code. À mon avis, la méthodologie TDD est très utile lors de ces mises à jour... mais il faut commencer par elle.

C'est également utile lorsque d'autres développeurs examinent votre code plus tard et ne parviennent pas à comprendre comment leur modification l'a cassé, ou s'ils essaient de réparer quelque chose que VOUS avez cassé accidentellement avant de quitter cet endroit.

Gardez à l'esprit que mon expérience de TDD est limitée parce que j'ai du mal à convaincre qui que ce soit de commencer un projet en l'utilisant... mais tous les projets que j'ai réalisés en utilisant TDD étaient plus faciles à maintenir grâce à cela.