Si les tests unitaires sont si importants, pourquoi n’y a-t-il pas plus de sociétés qui le font?

La première vraie société de logiciels à laquelle j’ai travaillé était celle des tests unitaires (NUnit). Je ne sais pas si nous étions de vrais sticklers à l’époque – je n’ai aucune idée de la couverture de notre code et j’écrivais la plupart des tests unitaires. Depuis lors, je suis tombé sur des entresockets qui effectuent de nombreux tests, mais il s’agit de tests par chaise: il faut être présent, avoir une faible répétabilité et peu de chances d’attraper des bugs. L’autre attitude est la suivante: c’était quelque chose qu’ils voulaient faire avec «dans le futur»; fondamentalement quand l’argent tombe du ciel.

Les tests unitaires me manquent – cela rend la vie plus facile. Mais je constate que lorsque je cherche un nouvel emploi, les tests unitaires sont soit quelque chose que les entresockets aimeraient «mettre en place» à l’avenir ou quelque chose qu’elles ne font pas du tout (euh, ça fait un moment à présent!). Je dirais que 60 à 75% des demandes d’emploi que j’ai examinées au cours des deux dernières années ne mentionnent aucun test d’unité. Je ne peux penser qu’à une ou deux personnes ayant besoin d’une expérience de test unitaire (pour un poste de développeur de niveau intermédiaire).

Donc, la question est: qu’est-ce qui manque ? Je pense que cela rend les gens plus productifs, mais c’est seulement après avoir passé beaucoup de temps à le faire. N’y a-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 un défenseur des démons, je me considère comme un partisan des tests unitaires.

Dans mon expérience, il y a quelques facteurs impliqués dans ceci:

  1. La direction ne comprend pas vraiment ce que sont vraiment les tests unitaires ou pourquoi elle présente une réelle valeur insortingnsè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 objective.
  3. Il y a une perception erronée que les tests appartiennent uniquement à la qualité de l’assurance qualité. Les développeurs sont des codeurs et ne peuvent pas écrire de tests.
  4. Il existe une perception erronée commune selon laquelle la direction devra dépenser de l’argent pour effectuer des tests unitaires correctement, malgré le fait que les outils soient disponibles gratuitement. (Bien sûr, le développeur prend le temps de réfléchir, mais ce n’est pas vraiment prohibitif.)
  5. La réponse de Will contournera cette réponse: il est très difficile de déterminer la valeur du code de test (edit jcollum)

Naturellement, il existe d’autres facteurs, mais c’est exactement ce que j’ai rencontré jusqu’ici.

1) C’est dur
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. De 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 celles-ci ne correspondent pas parfaitement à la feuille de calcul de votre responsable commercial.

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

La direction en général ne vous dit pas (et ne devrait probablement pas) vous dire comment faire votre travail, que ce soit la modularisation, les types de données abstraits, les modèles de conception ou les tests unitaires. Ce sont des outils commerciaux qu’un ingénieur logiciel compétent et compétent applique, mais pas un ingénieur médiocre.

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

C’est facile quand vous écrivez votre propre classe de cordes. Lorsque vous testez un produit réel, vous rencontrez des difficultés 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 testez-vous d’une 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 kernel Windows, comment le testez-vous? Ecrivez-vous des stubs pour chaque fonction IRP et kernel que vous utilisez, créant ainsi une simulation du kernel du système d’exploitation?
  • Les communications de réseau sont la chose du 21ème siècle. Comment coordonnez-vous un test unitaire composé de plusieurs composants dissortingbués?
  • Comment choisissez-vous de bons cas de test? Je vois souvent des personnes 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 testez-vous que les exigences de performance sont remplies?
  • La connaissance des modèles dans les tests est rare: les souches, les réponses en boîte, les tests de régression sont des concepts que la plupart des gens ne connaissent pas. Combien de personnes dans votre lieu de travail ont lu 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, indiquez 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 code unittest qui échoue si le fichier n’existe pas et réussit si le fichier existe. Génial! Avez-vous vérifié s’il fonctionne avec le nom de fichier dans BIG5 chinois? 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 travailler, les tests doivent être écrits par quelqu’un d’autre, uniquement pour les spécifications publiées sans qu’ils voient le code. – Dans la plupart des entresockets, le simple fait d’obtenir 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’access aux données, les bibliothèques mathématiques, etc., où les entrées / sorties sont bien connues et la structure interne complexe, mais dans de nombreux cas, elles ne sont qu’une perte de temps.
Ils échouent lorsque les erreurs sont dues à des interactions entre différentes parties du code ou avec le système d’exploitation et l’utilisateur. Des problèmes tels que des parameters PPP élevés / faibles perturbent une boîte de dialog ou un paramètre de langue étrangère remplaçant un paramètre ‘.’ et ‘,’ ne sont généralement pas trouvés.

Des études ont été réalisé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. Il semble toujours y avoir beaucoup de travail avec peu de profit lorsque vous commencez. Personne ne veut s’inscrire à un travail supplémentaire et résiste. Une fois que les gens commencent, ils s’en tiennent généralement avec enthousiasme, mais il peut être difficile de les démarrer.

Mis à part la question de l’adoption des tests unitaires, les tests unitaires ne sont pas toujours utiles, même si, en général, ils sont appliqués correctement. Il n’ya rien de spécial dans les tests unitaires qui les empêchent d’être vulnérables à une mauvaise construction.

Les tests unitaires ont des coûts (création, maintenance et exécution) et ne valent 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 expérience suffisante, il est très facile pour les développeurs, même les plus 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 est 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 la seule solution. Dans certaines circonstances et avec certaines équipes, ce n’est peut-être pas le moyen le plus efficace d’augmenter la qualité du logiciel.

Gardez à l’esprit que mettre beaucoup d’efforts dans les tests unitaires n’est pas une garantie de qualité des logiciels. De plus, il est possible de produire des logiciels de la plus haute qualité sans aucun test d’unité quelconque.

Eh bien, mon entreprise n’a pas utilisé TDD ou Unit Testing. Pour être honnête, nous ne soaps pas comment le faire. Nous pouvons évidemment le faire pour des fonctions stupides comme CapitalizeSsortingng (), etc., mais nous ne soaps pas comment le faire pour des systèmes très complexes avec des objects 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 pour la foule, mais pas particulièrement pour le pool de travail disponible.

TDD est un sujet distinct. Nous sums moralement opposés à TDD. Nous ne sums pas des codeurs de cow-boys, mais nous pensons que cela freine la créativité et la flexibilité dans 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 dans tous les cas extrêmes auxquels je peux penser. Ce dont j’ai besoin, c’est d’un autre cerveau pour chercher des choses que j’ai pu manquer. Nous n’avons pas ça. Les équipes sont petites et autonomes.

En bref, nous ne croyons pas en TDD, mais nous aimerions tester les unités. Nous n’avons tout simplement pas l’expérience pour le faire et nous ne pouvons pas le trouver facilement.

Il existe de nombreuses sociétés qui ne font vraiment rien dans le sens des meilleures pratiques. Pas de revues de code, pas de tests unitaires, pas de plans de tests, rien, rien que par le siège de leur pantalon.

Prenez cela comme une opportunité de les amener à utiliser une plate-forme d’continuous integration et à développer des tests unitaires! Un moyen facile d’impressionner les pouvoirs et d’augmenter la qualité et la stabilité de votre code en même temps

Edit: En ce qui concerne la raison, je pense qu’ils ne sont tout simplement pas au courant des outils actuels qui rendent les tests d’IC ​​et d’unités extrêmement faciles.

Les tests unitaires ne devraient être qu’une partie naturelle du workflow 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 peu de chances d’avoir une telle influence. Ainsi, la question de savoir si une entreprise est un partisan des tests unitaires dépend de la présence d’un développeur ou d’un architecte principal qui préconise les tests unitaires.

Je crois que c’est la réponse à votre question “Qu’est-ce qui manque et pourquoi il n’y a pas plus d’entresockets qui font des 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 de TDD. Si vous voulez externaliser votre informatique, vous pouvez montrer combien vous payez par an pour les employés que vous avez sous la main contre le coût de la sous-traitance; c’est très concret. Comment dites-vous, “Oh, ce test a détecté un bug qui m’a pris 4 heures pour déboguer et réparer …”?

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

En plus de cela, vous construisez une équipe (ou quelqu’un d’autre) doit mettre en place l’infrastructure et la maintenir.

Et comme le dit Alan , beaucoup d’endroits n’utilisent tout simplement pas les meilleures pratiques – ils veulent juste voir quelque chose de tangible.

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 consistant à «tout mettre en œuvre» sont les principaux obstacles à la réalisation des tests unitaires. En outre, les endroits où nos systèmes échouent ont tendance à se situer davantage au niveau de l’intégration (services, access à la firebase database, requêtes complexes nécessitant des données spécifiques pour les tests) et non au «niveau de l’unité». Ces choses sont plus difficiles à tester et si vous avez à peine le temps d’obtenir la fonctionnalité, vous n’aurez probablement pas le temps de faire des tests utiles en même temps.

Je pense que le programmeur doit juste commencer à le faire. Quelques tests simples au départ 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 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. Il suffit de mettre un commentaire expliquant où se trouve le test et comment l’exécuter. Les futurs programmeurs le verront et, espérons-le, les tests se propageront!

D’après ce que j’ai vu, de nombreuses entresockets disposent d’énormes bases de code fortement couplées qui ne sont pratiquement pas testables. Ils n’ont pas non plus d’exigences vérifiables décentes, de sorte que les tests unitaires testent les exigences de facto “telles que construites”.

Les tests unitaires sont l’un des termes cités dans la boîte noire que la plupart des gens ont entendus, mais ne savent pas exactement ce qu’est un test unitaire, par où commencer, comment les écrire, comment les tester, etc. . etc.

Dans de nombreux cas, il est plus facile pour le développeur incertain de les rejeter comme inutiles ou comme un givrage que seuls les «développeurs de niveau entreprise» ont besoin.

Je suis un grand fan des tests unitaires et je suis également associé dans une entreprise qui réalise des projets de développement de contrats pour différents types de clients. En un mois, nous aborderons 3 ou 4 projets différents de tailles différentes.

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

Considérant que si je construis quelque chose qui, je le sais, 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 survient , Je vais investir dans plus de tests unitaires. Là encore, la priorité des tests tourne autour du code incertain / peu familier / changeant.

Je pense que les tests unitaires devraient s’articuler autour de la complexité d’une tâche et de son efficacité. Il n’y a aucun sens à écrire du code supplémentaire qui ne va pas être utilisé.

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

Les tests unitaires me manquent – cela rend la vie plus facile.

Ce n’est pas vraiment une raison suffisante pour qu’une entreprise adopte des tests unitaires.

Une raison suffisante pourrait être “moins chère” (et / ou “meilleure”): ce qui n’est pas aussi facile à prouver sur les tests unitaires.

La seule bonne raison pourrait être que «l’écriture des tests unitaires est la meilleure utilisation du temps des développeurs», ce qui est vraiment difficile à prouver. Cela peut être vrai dans certains endroits, pour certains logiciels, avec certains développeurs et non.

Il y a beaucoup de développeurs qui ne pensent pas au monde des tests unitaires: y compris ceux qui pensent que d’autres formes de tests (intégration automatisée / tests fonctionnels, par exemple) peuvent être moins chères et plus rentables. t aime les tests unitaires?

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

Cependant, que vous écriviez un test unitaire dépend de plusieurs facteurs:

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

  • Combien de personnes maintiennent le code … si ce n’est que vous, alors vous le savez peut-être assez pour être suffisamment en confiance après avoir fait un changement pour vous assurer qu’un passage rapide du code est suffisant pour vous assurer que rien n’est cassé. Si d’autres personnes qui n’ont pas écrit le code à l’origine doivent maintenant le conserver, un test unitaire leur donnera l’assurance que lorsqu’elles mettent à jour le code pour corriger un gros (qui n’a évidemment pas été capturé dans le test unitaire!) .

  • complexité du code: seul le code de test nécessite un test. Une méthode d’affectation de variable à une ligne n’a pas besoin d’être testée. Une méthode de 50 lignes avec plusieurs chemins d’exécution peut être utile.

  • Considérations commerciales commerciales pratiques: Le fait que l’écriture des tests unitaires prend plus de temps que de ne pas le faire. Si vous écrivez des logiciels prototypes, qui ont un avenir commercial incertain, alors il est avantageux d’avoir du code rapidement, maintenant, qui fonctionne suffisamment bien par rapport au code testé par l’unité en 2 semaines qui fonctionne mieux. Parfois, il est utile de savoir rapidement (appétit du consommateur) si le logiciel aura une étagère courte et passera au projet suivant.

et comme d’autres l’ont fait remarquer, un test est aussi bon que celui qui l’a écrit.

La raison principale est que de nombreux développeurs et responsables de développement ne savent pas qu’il existe des tests unitaires ou comment les utiliser.

La deuxième raison est que les tests unitaires ne peuvent être utilisés (de manière sensée) qu’avec un code qui satisfait déjà à certaines normes de qualité. Il y a de fortes chances que certaines bases de code existantes ne rentrent pas dans cette catégorie.

La troisième raison est la paresse et / ou le bas prix.

Je pense qu’une partie du problème réside dans le fait que les développeurs attendent des gens d’affaires qu’ils aient le même ensemble de valeurs et qu’ils se soucient vraiment de la réponse à «devrions-nous tester ou non les unités? 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 la manière sensée de faire le travail.

Le fait est que nous sums 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 de test unitaire (ou nom-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 sur la plupart des choses que nous faisons avec une granularité trop fine. Pourquoi les tests unitaires sont-ils conformes à cette norme de preuve déraisonnable / non typique?

Les gens sont paresseux et n’adoptent le changement que lorsqu’ils sont obligés de le faire.

Mes 2 centimes:

  • Cela exige un peu d’éducation et de discipline, mais les nouveaux diplômés possèdent déjà les connaissances nécessaires.
  • Les tests généraux peuvent être réduits avec de meilleurs outils et cela se produit également (refactoring etc.)

Donc, c’est juste une question de temps.

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

“De nos jours, il est irresponsable qu’un développeur expédie une ligne de code qu’il n’a pas exécutée dans un test unitaire.”

[ http://www.infoq.com/interviews/coplien-martin-tdd%5D

Si vous voulez vendre tout le monde sur les tests, procédez comme suit:

  1. Ecrivez un tas de tests.
  2. Avertissez les autres développeurs qui changent de code et échouent à vos tests.
  3. Ils vont réparer leur code.
  4. Maintenant, vous pouvez libérer sans ces bogues particuliers.

Même un gestionnaire pouvait comprendre cela.

Les entresockets n’effectuent pas de tests unitaires, pour la même raison que beaucoup de sites Web sont mal rédigés – l’ignorance et les personnes qui ont 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 nous commercialisons le logiciel plus rapidement .

Comme la plupart des bonnes idées, l’adoption est davantage liée à la dépendance au plan organisationnel qu’à la qualité de l’idée.

Dans la plupart des entresockets qui ont expédié des produits, une division QA substantielle 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 QA écrive un code de test unitaire car l’entreprise ne dispose généralement pas de l’équipe QA avec ses codeurs lourds.

L’équipe de programmation est réticente à écrire du code de test car cela crée un conflit avec l’équipe d’assurance qualité.

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

Il est simple d’écrire et de mettre à jour des tests unitaires. La plupart des logiciels antérieurs 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, de sorte qu’ils ne l’ajoutent pas non plus aux nouvelles fonctionnalités.

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

Deux choses sont des obstacles aux tests unitaires

  1. Tout ce qui est nouveau est difficile à faire
  2. Tout ce qui n’a pas de profit mesurable est mauvais.
  3. Les humains sont paresseux. Les développeurs, en effet.

Dans mon entreprise (> 5.000 emp), les tests unitaires “sont là”, mais aucune chance de faire TDD ou d’obtenir une couverture de code importante. C’est difficile à accomplir.