Si les tests unitaires sont si efficaces, pourquoi les entreprises ne sont-elles pas plus nombreuses à les réaliser ?

Question

La première véritable société de logiciels dans laquelle j'ai travaillé était axée sur les tests unitaires (NUnit). Je ne sais pas si nous y tenions vraiment à l'époque - je n'ai aucune idée de la couverture de notre code et c'est moi qui écrivais la plupart des tests unitaires. Depuis lors, j'ai rencontré des entreprises qui effectuent beaucoup de tests, mais il s'agit de tests sur chaise : ils dépendent de la présence d'une personne, sont peu reproductibles et ont peu de chances de détecter les bogues. L'autre attitude est la suivante : c'était quelque chose qu'ils voulaient mettre en place "dans le futur" ; en gros, quand l'argent tombera du ciel.

Les tests unitaires me manquent - ils rendent la vie plus facile. Mais je constate que lorsque je cherche un nouvel emploi, les tests unitaires sont soit quelque chose que les entreprises aimeraient mettre en place à l'avenir, soit quelque chose qu'elles ne font pas du tout (euh, ça fait un moment que ça existe !). Je dirais que 60 à 75% des offres d'emploi que j'ai consultées au cours des deux dernières années ne mentionnaient pas du tout les tests unitaires. Je ne peux penser qu'à une ou deux offres d'emploi pour lesquelles l'expérience des tests unitaires était une exigence (pour un poste de développeur de niveau intermédiaire).

La question est donc la suivante , ce qui manque ? Je pense que cela rend les gens plus productifs, mais seulement après avoir passé beaucoup de temps à le faire. N'y a-t-il pas de bonnes études sur les économies réalisées grâce aux tests unitaires ? Est-ce le type d'entreprise que je recherche ?

Edit : même si le titre est un peu diabolique, je me considère comme un partisan des tests unitaires.

Answer 1

D'après mon expérience, plusieurs facteurs entrent en ligne de compte :

1. La direction ne comprend pas vraiment ce que sont les tests unitaires, ni pourquoi ils ont une réelle valeur intrinsèque pour elle.
2. La direction a tendance à se préoccuper davantage de la livraison rapide des produits et considère (à tort) que les tests unitaires vont à l'encontre de cet objectif.
3. Il existe une perception erronée selon laquelle les tests appartiennent uniquement au domaine 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 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 viendra compléter cette réponse : Il est très difficile de déterminer la valeur du code de test (edit jcollum)

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

Answer 2

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 une question épineuse. De bons tests unitaires réduisent les bogues. Mais un bon code de production aussi. Comment déterminer combien de bogues n'existent pas grâce à vos tests unitaires ? Vous ne pouvez pas mesurer ce qui n'existe pas. Vous pouvez vous référer à des études, mais elles n'ont pas leur place sur la feuille de calcul de votre directeur commercial.

Answer 3

Il est facile de rejeter toute la responsabilité sur la "direction". Mais la direction est-elle vraiment en vous disant spécifiquement pas faire des tests unitaires ?

La direction en général ne vous dit pas (et ne devrait probablement pas) 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 de travail qu'un ingénieur logiciel compétent et performant utilise, 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 lorsque vous écrivez votre propre classe de chaînes. Lorsque vous testez un produit réel, vous rencontrez des difficultés dont personne ne vous a parlé dans les diapositives Powerpoint :

• L'interaction avec l'utilisateur. La moitié de votre application est constituée par la logique de l'interface utilisateur. Comment la tester de manière automatisée, sans qu'elle ne tombe en panne 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 ? Ecrivez-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 en réseau sont la chose du 21e siècle. Comment coordonner un test unitaire composé de plusieurs composants distribués ?
• Comment choisir de bons cas de test ? Je vois souvent des gens qui essaient 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 supérieur au rendement, des bogues importants sont manqués et les tests unitaires sont abandonnés.
• Comment vérifier que les exigences de performance sont respectées ?
• La connaissance des modèles de test est rare : les stubs, les réponses automatiques, les tests de régression sont des concepts que la plupart des gens ne connaissent pas. Combien de personnes sur votre lieu de travail ont lu un livre sur les tests unitaires ?

La seule chose que l'on peut reprocher à la direction est que les spécifications des exigences contiennent rarement des exigences sur le niveau de qualité du produit livrable.

La prochaine fois que votre patron vous demandera de faire une estimation du temps, incluez le temps d'écriture d'un test unitaire et voyez ce qui se passe.

Answer 4

La plupart des tests ne testent rien du tout.
Vous écrivez une fonction fileopen() et unittest qui échoue si le fichier n'existe pas et réussit si le fichier existe. Super ! 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 l'UAC activé ?

Le problème est que les tests unitaires sont écrits par le même programmeur qui a écrit la fonction, selon les mêmes 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 selon les spécifications publiées, sans qu'ils voient le code. - Dans la plupart des entreprises, le simple fait d'obtenir des spécifications écrites serait une avancé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 la plupart des cas, ils 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 paramètres DPI élevés/faibles perturbant une boîte de dialogue ou un paramètre de langue étrangère intervertissant un '.' et ',' ne sont généralement pas trouvés.

Answer 5

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