Si les tests unitaires sont si bons, pourquoi n'y a-t-il pas plus d'entreprises qui le font? [fermé]

La première véritable société de logiciels dans laquelle j'ai travaillé était entièrement consacrée aux tests unitaires (NUnit). Je ne sais pas si nous étions de vrais persévérants à l'époque - je n'ai aucune idée de la couverture de notre code et j'écrivais la plupart des tests unitaires. Depuis, j'ai rencontré des entreprises qui font beaucoup de tests, mais c'est des tests de chaise: repose sur la présence d'une personne, a une faible répétabilité et de faibles chances d'attraper des bogues. L'autre attitude est: c'était quelque chose avec lequel ils voulaient se lancer «dans le futur»; essentiellement quand l'argent tombe du ciel.

Les tests unitaires me manquent - cela me facilite la vie. Mais je constate que lorsque je cherche un nouvel emploi, les tests unitaires sont soit quelque chose que les entreprises aimeraient «faire» à l'avenir, soit quelque chose qu'elles ne font pas du tout (euh, ça existe depuis un moment maintenant!). Je dirais que 60 à 75% des demandes d'emploi que j'ai examinées au cours des 2 dernières années n'ont pas du tout répertorié les tests unitaires. Je ne peux penser qu'à un ou deux qui avaient une expérience de test unitaire comme exigence (pour un poste de développeur de niveau intermédiaire).

La question est donc de savoir ce qui manque ? Je pense que cela rend les gens plus productifs, mais ce n'est qu'après avoir passé beaucoup de temps à le faire. N'existe-t-il pas de bonnes études sur les économies de coûts des tests unitaires? Est-ce le type d'entreprise que je regarde?

Edit: même si le titre est un peu l'avocat du diable, je me considère comme un partisan des tests unitaires.

D'après mon expérience, plusieurs facteurs sont impliqués:

1. La direction ne comprend pas vraiment ce qu'est réellement le test unitaire, ni pourquoi il a une réelle valeur intrinsèque pour eux.
2. La direction a tendance à se préoccuper davantage de la livraison rapide des produits et considère (à tort) que les tests unitaires sont contre-productifs pour atteindre cet objectif.
3. Il y a une perception erronée selon laquelle les tests appartiennent uniquement à l'assurance qualité. Les développeurs sont des codeurs et ne peuvent pas écrire de tests.
4. Il y a une idée fausse courante selon laquelle la direction devra dépenser de l'argent pour effectuer correctement les tests unitaires, malgré le fait que les outils sont disponibles gratuitement. (Il y a, bien sûr, le temps de montée en puissance du développeur à prendre en compte, mais ce n'est pas vraiment prohibitif.)
5. La réponse de Will arrondira cette réponse: il est très difficile de déterminer la valeur du code de test (modifier jcollum)

Naturellement, il y a d'autres facteurs, mais ce sont exactement ce que j'ai rencontré jusqu'à présent.

1) C'est difficile
2) Cela prend du temps
3) Il est très difficile de déterminer la valeur du code de test

Le point 3 est collant. Les bons tests unitaires réduisent les bogues. Mais il en va de même pour un bon code de production. Comment déterminez-vous combien de bogues n'existent pas à cause de vos tests unitaires? Vous ne pouvez pas mesurer ce qui n'existe pas. Vous pouvez indiquer des études, mais elles ne correspondent pas bien à la feuille de calcul de votre responsable commercial.

Il est facile de rejeter tout le blâme sur la «gestion». Mais la direction vous dit-elle vraiment de ne pas faire de test unitaire?

La direction en général ne vous dit pas (et ne devrait probablement pas) vous dire comment faire votre travail, qu'il s'agisse de modularisation, de types de données abstraits, de modèles de conception ou de tests unitaires. Ce sont des outils du métier qu'un ingénieur logiciel compétent et performant applique, mais pas un mauvais ingénieur.

Je pense que la vraie réponse à votre question est: les tests unitaires sont vraiment difficiles et les étudiants en informatique ne sont pas formés pour cela.

C'est facile lorsque vous écrivez votre propre classe de chaînes. Lorsque vous testez un produit réel, vous rencontrez des défis dont personne ne vous a parlé dans les diapositives PowerPoint:

• Interaction de l'utilisateur. La moitié de votre application est la logique de l'interface utilisateur. Comment le tester de manière automatisée, qui ne se décompose pas si vous déplacez un bouton?
• Interaction avec des API et des frameworks externes. Si vous écrivez un pilote de noyau Windows, comment le testez-vous unitaire? Écrivez-vous des stubs pour chaque IRP et fonction du noyau que vous utilisez, créant ainsi une simulation du noyau du système d'exploitation?
• Les communications réseau sont la chose du 21e siècle. Comment coordonnez-vous un test unitaire composé de plusieurs composants distribués?
• Comment choisissez-vous de bons cas de test? Je vois souvent des gens essayer l'approche «faire des choses aléatoires dans une boucle de 1000 itérations et voir si ça casse». Lorsque vous faites cela, l'effort est plus élevé que les retours, des bogues importants sont manqués et les tests unitaires sont abandonnés.
• Comment vérifiez-vous que les exigences de performance sont satisfaites?
• La connaissance des modèles de test est rare: les stubs, les réponses standardisées, les tests de régression sont des concepts que la plupart des gens ne connaissent pas. Combien sur votre lieu de travail lisent réellement un livre sur les tests unitaires?

La seule chose que nous pouvons reprocher à la direction est que les spécifications des exigences contiennent rarement des exigences sur le niveau de qualité du livrable.

La prochaine fois que votre patron vous demandera de faire une estimation du temps, incluez le temps nécessaire pour rédiger un test unitaire et voyez ce qui se passe.

La plupart des tests ne testent rien.
Vous écrivez une fonction fileopen () et un test unitaire qui échoue si le fichier n'existe pas et réussit si le fichier existe. Génial! Maintenant, avez-vous vérifié si cela fonctionne avec le nom de fichier en chinois BIG5? sur un partage NFS? sur vista avec le fichier sur une clé USB et UAC activé?

Le problème est que les tests unitaires sont écrits par le même programmeur qui a écrit la fonction, avec le même ensemble d'hypothèses et avec le même niveau de compétence. Pour vraiment fonctionner, les tests doivent être écrits par quelqu'un d'autre, uniquement sur les spécifications publiées sans qu'ils voient le code. - Dans la plupart des entreprises, le simple fait de recevoir des spécifications écrites serait une percée!

Les tests unitaires vérifient les erreurs dans le code des fonctions individuelles. Ils peuvent fonctionner pour les couches d'accès aux données, les bibliothèques mathématiques, etc. où les entrées / sorties sont bien connues et la structure interne est complexe, mais dans de nombreux cas, ce n'est qu'une perte de temps.
Ils échouent lorsque les erreurs sont dues à des interactions entre différentes parties de code ou avec le système d'exploitation et l'utilisateur. Des problèmes tels que des paramètres DPI haut / bas qui gâchent une boîte de dialogue ou un paramètre de langue étrangère permutant un «.» et ',' ne sont généralement pas trouvés.

Des études ont été effectuées sur le retour sur investissement des tests unitaires - voir cette question .

J'ai trouvé beaucoup de développeurs qui ne sont pas intéressés par les tests unitaires. Cela semble toujours être beaucoup de travail avec peu de gains lorsque vous commencez. Personne ne veut s'inscrire pour un travail supplémentaire et donc ils résistent. Une fois que les gens commencent, ils s'y tiennent généralement avec enthousiasme, mais les faire démarrer peut être difficile.

Mis à part la question de l'adoption des tests unitaires, les tests unitaires ne valent pas toujours la peine, bien qu'en général je pense que c'est le cas, lorsqu'ils sont appliqués correctement. Il n'y a rien de spécial dans les tests unitaires qui les évite d'être vulnérables à une mauvaise construction.

Les tests unitaires ont des coûts (création, maintenance et exécution) et ne valent la peine que s'ils offrent des avantages plus importants que ces coûts. La création de tests est une compétence comme les autres, elle nécessite une expérience et des connaissances spécifiques pour réussir. Sans une expérience suffisante, il est très facile, même pour les développeurs expérimentés, de créer des tests unitaires de faible qualité, de faible valeur et / ou de coût élevé qui ne valent pas la peine. D'autant plus qu'il peut être difficile de juger de la valeur d'un test unitaire.

De plus, les tests unitaires ne sont qu'un moyen d'améliorer la qualité du code, mais ce n'est pas le seul. Dans certaines circonstances et avec certaines équipes, ce n'est peut-être pas le moyen le plus efficace d'augmenter la qualité des logiciels.

Gardez à l'esprit que consacrer beaucoup d'efforts aux tests unitaires ne garantit pas la qualité des logiciels. De plus, il est possible de produire des logiciels de la plus haute qualité sans aucun test unitaire.

Eh bien, mon entreprise n'a pas opté pour le TDD ou les tests unitaires. Pour être honnête, nous ne savons pas comment le faire. Nous pouvons évidemment le faire pour des fonctions stupides comme CapitalizeString (), etc., mais nous ne savons pas comment le faire pour des systèmes très complexes avec des objets compliqués. De plus, la plupart des personnes interrogées n'ont aucune expérience ou une expérience limitée. Il semble que les tests unitaires soient importants par rapport à la foule SO, mais pas particulièrement importants dans le pool de travail disponible.

Le TDD est un sujet distinct. Nous sommes moralement opposés au TDD. Nous ne sommes pas des codeurs de cow-boy, mais nous pensons que cela freine la créativité et la flexibilité d'un projet. De plus, avoir le codeur qui a écrit la fonction de test unitaire n'a aucun sens. Quand je fais quelque chose, je code sur tous les cas extrêmes auxquels je peux penser. Ce dont j'ai besoin, c'est d'un autre cerveau pour rechercher des choses que j'ai pu manquer. Nous n'avons pas ça. Les équipes sont petites et autonomes.

Bref, nous ne croyons pas au TDD, mais nous aimerions faire un test unitaire. Nous n'avons tout simplement pas l'expérience pour le faire et nous ne pouvons pas le trouver facilement.

Il existe de nombreuses entreprises qui ne font vraiment rien dans le sens des meilleures pratiques. Pas de révision de code, pas de test unitaire, pas de plan de test, pas de rien, juste à côté du siège de leur pantalon.

Profitez-en pour leur faire utiliser une plateforme d'intégration continue et développer des tests unitaires! Un moyen facile d'impressionner les pouvoirs en place et d'augmenter la qualité et la stabilité de votre code en même temps

Edit: Quant à la raison, je pense qu'ils ne sont tout simplement pas au courant des outils actuels qui rendent les tests CI et unitaires extrêmement faciles.

D'après ce que j'ai vu, de nombreuses entreprises ont d'énormes bases de code hautement couplées qui ne sont pas pratiquement testables à l'unité. Ils n'ont pas non plus d'exigences testables décentes, donc les tests unitaires seraient testés par rapport aux exigences de facto "as built".

Je ne pense pas que la paresse soit la cause première des mauvais tests unitaires. Pour mon entreprise, les contraintes de temps et l'attitude «juste faire ça» sont les plus grands dissuasifs pour faire des tests unitaires. En outre, les endroits où nos systèmes échouent ont tendance à se situer davantage au niveau de l'intégration (services, accès aux bases de données, requêtes complexes qui nécessitent des données spécifiques pour les tests), et non au «niveau de l'unité». Ces choses sont simplement plus difficiles à tester, et si vous avez à peine le temps de faire la fonctionnalité, vous n'aurez probablement pas le temps de faire des tests utiles en même temps.

Les tests unitaires doivent être une partie naturelle du flux de travail de développement de code, tout comme le compilateur.

Cependant, cela nécessite d'éduquer la direction sur les avantages des tests unitaires. Les développeurs juniors ont cependant des chances relativement faibles d'avoir une telle influence. Ainsi, si une entreprise est un partisan des tests unitaires dépend du fait qu'elle ait un développeur ou un architecte senior qui est un partisan des tests unitaires.

Je pense que c'est la réponse à votre question "ce qui manque et pourquoi les entreprises ne font-elles pas plus de tests unitaires" . :-)

C'est probablement une combinaison de deux choses que vous avez déjà mentionnées. Il est difficile de mesurer les économies de coûts du TDD. Si vous souhaitez externaliser votre informatique, vous pouvez montrer combien vous payez par an pour les employés que vous avez par rapport au coût de la sous-traitance; c'est très concret. Comment dire, "Oh, ce test a détecté un bogue qui m'aurait pris 4 heures pour déboguer et corriger ..."?

La raison pour laquelle certains endroits ne l'utilisent pas est simplement parce qu'il faut beaucoup de travail à la fois pour démarrer et pour continuer. Le fait que l'écriture de tests unitaires prenne environ autant de temps que l'écriture de la fonctionnalité réelle semble à certains gestionnaires comme si vous réduisiez de moitié la productivité de votre développeur.

En plus de cela, vous créez une équipe (ou quelqu'un) a besoin de mettre l'infrastructure en place et de la maintenir.

Et comme le dit Alan , de nombreux endroits n'utilisent tout simplement pas les meilleures pratiques - ils veulent juste voir quelque chose de tangible.

Je pense que le programmeur doit simplement commencer à le faire. Quelques tests simples pour commencer sont faciles à justifier dans le cadre du développement.

Quelque chose comme un test unitaire est presque toujours nécessaire pour obtenir un débogage rapide. Expliquez simplement à quel point il est beaucoup plus rapide de lancer le test que d'organiser la bonne entrée, de définir un point d'arrêt du débogueur, de lancer l'application, etc.

Documentez le test dans votre code. Mettez simplement un commentaire expliquant où se trouve le test et comment l'exécuter. Les futurs programmeurs le verront et j'espère que les tests se répandront!

Les tests unitaires sont l'un de ces termes de la boîte noire que la plupart des gens ont entendus, mais ne savent pas ce qui constitue exactement un test unitaire, par où commencer, comment les écrire, comment exécuter les tests, ce qu'ils devraient exactement tester, etc. . etc.

Dans de nombreux cas, il est plus facile pour le développeur incertain de simplement les rejeter comme inutiles ou comme un glaçage dont seuls les "développeurs au niveau de l'entreprise" ont besoin.

Je suis un grand fan des tests unitaires et je suis également partenaire dans une entreprise réalisant des projets de développement de contrats pour différents types de clients. Dans un mois, nous aborderons 3-4 projets différents de différentes tailles.

Si un projet semble être unique, je ne vais pas investir massivement dans les tests unitaires car ces tests unitaires ne sont pas rentables pour mon entreprise. Sur ces types de projets, je vais tester des éléments avec lesquels je ne suis pas sûr / que je ne suis pas familier ou qui pourraient changer fréquemment (comme un analyseur pour une source de données que je ne contrôle pas).

Alors que si je construis quelque chose dont je sais qu'il aura une longue durée de vie, est un travail plus important, avec lequel je travaillerai à travers plusieurs itérations, ou aura un impact important sur mes clients si une erreur se produit , Je vais investir dans plus de tests unitaires. Encore une fois, la priorité des tests tourne autour du code incertain / inconnu / changeant.

Je pense que les tests unitaires devraient tourner autour de la complexité d'une tâche, ainsi que de savoir s'ils vont porter leurs fruits. Il n'y a aucun sens à écrire du code supplémentaire qui ne sera pas utilisé.

D'après mon expérience, cela dépend vraiment du logiciel que vous écrivez. J'ai trouvé qu'il était extrêmement difficile d'écrire des tests unitaires pour une interface utilisateur. Je n'utilise que des tests unitaires pour les parties du système qui ont une entrée / sortie définie.

Les tests unitaires me manquent - cela me facilite la vie.

Ce n'est pas vraiment une raison suffisante pour qu'une entreprise adopte les tests unitaires.

Une raison suffisante pourrait être "meilleur marché" (et / ou "meilleur"): ce qui n'est pas aussi facile à prouver à propos des tests unitaires.

La seule bonne raison pourrait être «l'écriture de tests unitaires est la meilleure utilisation du temps des développeurs», ce qui est vraiment difficile à prouver IMO: et cela peut être vrai à certains endroits, pour certains logiciels, avec certains développeurs, et pas ailleurs.

Il y a beaucoup de développeurs qui ne pensent pas au monde des tests unitaires: y compris certains qui pensent que d'autres formes de tests (par exemple, l'intégration automatisée / les tests fonctionnels) peuvent être moins chères et plus précieuses, par exemple Suis-je le seul développeur à ne pas le faire? t comme les tests unitaires?

Bien sûr, dans le monde idéal, vous ne pouvez pas vous opposer à un test unitaire.

Cependant, le fait d'écrire un test unitaire dépend d'un certain nombre de choses:

• Comment le logiciel sera utilisé. Si vous écriviez un logiciel pour vous-même, écririez-vous des tests unitaires? Probablement pas. Si vous écriviez un logiciel pré-emballé destiné à être vendu dans le commerce, probablement oui.

• Combien de personnes maintiennent le code ... si ce n'est que vous, alors vous le savez peut-être assez bien pour être suffisamment confiant après avoir apporté une modification pour qu'une lecture rapide du code soit suffisante pour vous assurer que rien n'est cassé. Si d'autres personnes qui n'ont pas initialement écrit le code doivent maintenant le maintenir, un test unitaire les aidera à être sûrs que lorsqu'ils mettent à jour le code pour corriger un gros problème (ce qui n'a évidemment pas été capturé dans le test unitaire!), Ils n'ont rien cassé .

• complexité du code: uniquement le code de test qui nécessite un test. Une méthode d'attribution de variable en une ligne ne nécessite pas de test. Une méthode de 50 lignes avec plusieurs chemins d'exécution le fera probablement.

• Considérations commerciales commerciales pratiques: le fait est que l'écriture de tests unitaires prend plus de temps que de ne pas le faire. Si vous écrivez un logiciel prototype, qui a un avenir commercial incertain, alors il y a un avantage à avoir entre avoir un code rapidement, maintenant, qui fonctionne suffisamment bien et avoir un code testé à l'unité en 2 semaines qui fonctionne mieux. Parfois, il est avantageux de savoir rapidement (appétit du consommateur) si le logiciel aura une courte étagère et passer au projet suivant.

et comme d'autres l'ont souligné, un test n'est aussi bon que la personne qui l'a écrit.

La raison principale est que de nombreux développeurs et responsables de développement n'ont aucune idée de l'existence de tests unitaires ni de la manière de les utiliser.

La deuxième raison est que les tests unitaires ne peuvent être utilisés (de manière raisonnable) qu'avec du code qui répond déjà à certaines normes de qualité. Il y a de fortes chances que certaines bases de code existantes ne tombent pas dans cette catégorie.

La troisième raison est la paresse et / ou le bon marché.

Parce que les tests unitaires ne sont utiles que si vous écrivez du code testable. Et écrire du code testable est difficile. Et les gens sont paresseux et / ou bon marché.

EDIT: nuancé "paresseux" comme "paresseux et / ou bon marché"; dans de rares cas, les gens ont en fait les compétences, la capacité et la volonté de passer des tests, mais ils ont autre chose à faire qui affecte plus directement les résultats.

Je pense qu'une partie du problème est que les développeurs s'attendent à ce que les gens d'affaires aient le même ensemble de valeurs et qu'ils se soucient vraiment de la réponse à la question "Devrions-nous faire des tests unitaires ou pas?". Nous n'obtenons pas l'approbation préalable de l'entreprise pour utiliser un langage de haut niveau plutôt qu'un langage d'assemblage - c'est généralement le moyen le plus judicieux de faire le travail.

Le fait est que nous sommes les seuls qualifiés pour faire l'appel (ce qui ne veut pas dire que nous avons tous les mêmes connaissances sur le sujet). De plus, même si votre équipe ne fait pas, par politique, de tests unitaires (ou nommez-votre-méthode-du-jour), cela ne signifie généralement pas que vous ne pouvez pas le faire.

La vérité est que nous ne pouvons pas vraiment prouver le retour sur investissement de la plupart des choses que nous faisons avec une granularité trop fine. Pourquoi les tests unitaires sont tenus à la hauteur de cette norme de preuve déraisonnable / non typique me dépasse ...

Les gens sont paresseux et n'adoptent le changement que lorsqu'ils y sont contraints.

Mes 2 cents:

• Cela nécessite une certaine éducation et discipline, mais les nouveaux diplômés possèdent déjà les connaissances nécessaires.
• La surcharge des tests peut être réduite avec de meilleurs outils et cela se produit également (refactoring, etc.)

Donc, ce n'est qu'une question de temps.

Il y a le débat Martin-Coplien dans lequel Bob Martin affirme que:

"de nos jours, il est irresponsable pour un développeur d'envoyer une ligne de code qu'il n'a pas exécutée dans un test unitaire."

[ http://www.infoq.com/interviews/coplien-martin-tdd]

Si vous souhaitez vendre tout le monde aux tests, procédez comme suit:

1. Écrivez un tas de tests.
2. Avertissez les autres développeurs qui changent de code et échouent à vos tests.
3. Ils corrigeront leur code.
4. Vous pouvez maintenant publier sans ces bogues particuliers.

Même un gestionnaire pourrait comprendre cela.

Les entreprises n'effectuent pas de tests unitaires, pour la même raison que de nombreux sites Web sont mal écrits - l'ignorance et les gens qui s'en tiennent à de vieilles habitudes. Dans mon entreprise, depuis que nous avons commencé les tests unitaires (avec Nunit et Typemock ), nous atteignons une couverture de code plus élevée et publions le logiciel dans un délai de commercialisation plus court.

Comme la plupart des bonnes idées, l'adoption a plus à voir avec la dépendance du chemin organisationnel qu'avec la qualité de l'idée.

Dans la plupart des entreprises qui ont expédié des produits, une importante division QA a été créée avec un responsable QA de haut niveau. Les tests sont le fief de l'équipe QA.

Il est peu probable que l'équipe d'assurance qualité écrive du code de test unitaire, car l'entreprise ne dispose généralement pas de l'équipe d'assurance qualité avec ses codeurs robustes.

L'équipe de programmation hésite à écrire du code de test car cela crée un conflit avec l'équipe d'assurance qualité.

J'ai vu plus d'intérêt et l'adoption des tests unitaires dans des groupes où l'assurance qualité n'a pas été transformée en une fonction de travail distincte

L'écriture et la mise à jour des tests unitaires coûtent de l'argent. La plupart des logiciels précédents des entreprises n'ont pas de tests unitaires et coûteront trop cher à écrire. Donc, ils ne le font pas et cela ajoute du temps au processus de développement afin qu'ils ne l'ajoutent pas non plus aux nouvelles fonctionnalités.

La plupart des entreprises sont inutiles. Pas celui pour lequel vous (ou moi) travaillons, évidemment.