Quelqu'un at-il des métriques sur l'utilité des tests unitaires formels?

Question

Quelqu'un a-t-il des statistiques sur l'utilité des tests unitaires formels? Je vois beaucoup d’attention portée aux outils de tests unitaires et j’étais curieux de savoir pourquoi?

J'ai arrêté les tests unitaires formels il y a 5 ou 6 ans et le gain net de productivité semble assez élevé. J'ai arrêté les tests unitaires parce que je me suis rendu compte que rien ne s'y trouvait - encore moins quelque chose d'utile. Le type d'erreurs détectées par les tests unitaires semble évitable en ne buvant pas plus de 2 verres de vin / bière par heure (ou 2 joints par heure). De plus, les tests unitaires semblent créer un risque en permettant au développeur de penser qu’il existe une protection contre les erreurs.

Je teste pour m'assurer que le code fonctionne correctement, mais je n'utilise aucun outil. Je teste en fonction des modifications apportées. Mon taux d'erreur de production pour le nouveau code est d'environ zéro. Mon taux d'erreur pour les modifications de code est d'environ 2-3 bugs par trimestre. Les mesures ci-dessus sont basées sur 4 applications de production que je développe / supporte.

Answer 1

Voici un fil qui a quelques recherches sur l'approche TDD Recherche sur le TDD

Existe-t-il des preuves tangibles du retour sur investissement de l'unité tester?

Answer 2

Je reconnais votre supériorité en tant qu'être humain et codeur.

Cependant, je ne suis qu'un crétin et, sans Python, je serais perdu.

Je ne peux pas refactoriser sans les tests unitaires, cela demande trop de réflexion.

Je peux à peine coder sans tests unitaires, il est trop difficile d'être absolument sûr de comprendre absolument toutes les nuances.

Je teste l'unité parce que je suis un idiot. Puisque vous ne faites pas d'erreur, vous n'avez clairement pas besoin de test unitaire. Je vous salue.

Modifier. Pour moi, les tests unitaires ne concernent ni les métriques ni les coûts. Je n'ai pas besoin d'expériences contrôlées randomisées pour me montrer la valeur. Je ne peux pas travailler sans eux. En effet, je refuse de travailler sans eux. De même, je ne travaillerai pas sans compilateur, éditeur de texte ou contrôle de code source; Je ne travaillerai pas sans exigences; Je refuse de programmer sans faire d'abord du design.

Answer 3

Je ne considère pas les tests unitaires comme un remplacement des tests traditionnels, mais plutôt comme une étape supplémentaire permettant de garantir l'exactitude du code. Les tests unitaires que je trouve utiles sont notamment les suivants:

• Lors de la refactorisation / modification du code existant. Les tests unitaires vérifieront qu'au moins ces cas fonctionnent toujours comme prévu. Plus vous avez de tests, plus vous pouvez être sûr que les modifications de code n'ont pas altéré le code existant.
• Lors de la soumission de rapports de bogues. Avoir un test unitaire qui expose un bogue est un excellent moyen de le démontrer ET de savoir quand il a été corrigé.
• Un moyen de concevoir des interfaces. Vous avez un code de test pour vérifier les interfaces avec.

Probablement quelques autres que j'ai oubliés :-P

PS: Comment savez-vous que vous ne faites pas de bugs? Je ne pense pas que j'insère des bogues dans le code sur lequel je travaille, mais cela ne le rend certainement pas ainsi. IMHO, il est naïf de penser que votre code est sans bug.

(En ce qui concerne les tests unitaires, si vous savez que votre code peut contenir des bogues - et la plupart des codes en contiennent, ne voudriez-vous pas utiliser tous les moyens possibles pour les intercepter?)

Answer 4

Voici un livre blanc sur le test unitaire qui pourrait vous aider:

• Livre blanc n ° 1
• Livre blanc n ° 2
• Livre blanc n ° 3

Mais, Martin Fowler , la preuve anecdotique à l'appui des tests unitaires et TDD est accablant, mais vous ne pouvez pas mesurer la productivité.

Les tests unitaires sont utiles car vous pouvez modifier une pièce et savoir si quelque chose a été modifié ailleurs. Certaines personnes sont "amoureuses" avec des tests unitaires et devrait se calmer. Je crois aux tests unitaires, mais les personnes qui tentent de tout dissimuler sont aussi dangereuses que les personnes qui ne subissent pas de tests unitaires.

Answer 5

Je n'ai aucune métrique à signaler, mais je pense que la popularité grandissante est due au fait que le reste d'entre nous a eu une expérience qui est à l'opposé de la vôtre. :)

Answer 6

Grâce aux tests unitaires, je peux corriger les bogues dans le code de production et installer la nouvelle version dans l’heure à laquelle le bogue a été détecté et je peux être sûr que la nouvelle version n’est pas pire que ce que nous avions auparavant - car les tests me disent alors. Ce pourrait être mieux, cependant.

Ils me donnent un filigrane inférieur en dessous duquel la qualité de mon code ne peut jamais sombrer. Ils me permettent de garder une vue d'ensemble et de faire en sorte que les tests trouvent les petites erreurs que j'ai tendance à commettre. Ils me permettent également de développer un style très décontracté.

Depuis que je teste, j’ai tendance à livrer dans les délais, la qualité de mon code s’est beaucoup améliorée et le résultat est généralement conforme aux attentes. De plus, je suis beaucoup plus rapide car je peux prendre des raccourcis, ce qui serait trop dangereux d'essayer si je ne subissais pas les tests.

Cela dit, je n’ai pas non plus de chiffres précis ni de sources bien que je fasse des tests unitaires et des tests de diagnostic dynamique pendant des années. Mon amour des tests repose sur le bouche à oreille et l'expérience personnelle.

Answer 7

J'ai constaté que le test unitaire m'aidait lors de l'ajout de nouvelles fonctionnalités. Dans ce scénario, j'avais l'habitude de craindre que ce que j'ajoutais allait casser quelque chose dans une partie distante de l'application. Mais avec les tests unitaires appropriés, je sais si j'ai cassé quelque chose au moment où je lance les tests.

Voici une discussion intéressante sur l’ utilité des tests unitaires .

Si vous n'aimez pas les tests unitaires, Design By Contract est un autre concept à étudier. . Ce qui signifie que si certaines conditions de départ sont remplies, le résultat garanti est conforme au contrat.

Answer 8

Je suis un responsable du développement. Pour mon organisation, la configuration et la migration vers nhibernate impliquaient des coûts de configuration et un temps de développement supplémentaire. Certains développeurs l'ont aimé, d'autres ont pensé que c'était une perte de temps.

Il n'y a pas eu de changement notable dans les taux d'erreur, mais il est peut-être trop tôt pour le dire.

De mon point de vue, je pense que cela aide les développeurs débutants qui ne sont pas sûrs de leur travail, mais pour les développeurs chevronnés, cela semble les ralentir - c’est une dernière chose à garder à jour. Je ne sais pas si nous allons continuer à utiliser cela, revenir à nos anciennes méthodes (tests unitaires ad hoc) ou laisser les développeurs faire un choix personnel.

Answer 9

Plusieurs outils mesurent la couverture de code avec des tests unitaires. Ils constituent une partie essentielle du test unitaire pour s’assurer que le code est non seulement testé, mais également intégralement.

Tout le reste n'est que pure magie;)

Answer 10

Si vous voulez refactoriser le code, vous avez par définition besoin d'un moyen de savoir si les modifications ont rompu le code. Manquant de perspicacité divine, je trouve que les tests unitaires sont un très bon outil, mais ymmv.

Answer 11

J'ai eu beaucoup de gain en utilisant TDD (Test Driven Development) avec C ++ sur une énorme application serveur monolithique.

Lorsque je travaille sur une zone de code, je vérifie tout d'abord que cette zone est couverte de tests avant de modifier ou d'écrire un nouveau code.

Dans ce cas d'utilisation, mes gains de productivité sont énormes.

• Pour créer et exécuter mon test: 10 secondes.
• Pour créer, exécuter et tester manuellement le serveur complet: 5 minutes minimum.

Cela signifie que je suis capable d'itérer une zone de code très rapidement et de ne tester complètement que lorsque j'en ai besoin.

De plus, j’ai également utilisé des tests d’intégration qui prennent plus de temps à construire et à exécuter, mais n’exercent que la fonctionnalité spécifique qui m’intéresse.

Answer 12

J'ai de la sympathie pour ce que vous dites. Mon expérience est similaire en ce sens que mes nouveaux bogues sont rarement capturés par les tests unitaires. Le cas échéant, les tests unitaires sont modifiés après la découverte du bogue pour s'assurer qu'il ne réapparaît pas.

Les tests unitaires m’ont aidé dans la conception de mes classes (Java). J'ai souvent refactorisé les classes pour les rendre testables (suppression de singletons par exemple), ce qui a, je pense, amélioré la conception générale. Pour moi, c'est une raison suffisante pour les utiliser.

Answer 13

D'après mon expérience, les tests unitaires m'ont aidé avec les tâches suivantes:

• Maintenant, je peux me concentrer entièrement sur le bloc de code / la fonction / la classe que j'écris sans me soucier de rien d'autre, car je sais que si je fais quelque chose de stupide ou que je provoque un effet secondaire, mes tests me diront
• Je peux refacturer des trucs en sachant que je ne casse pas de trucs
• Je suis sûr que mon application fonctionne comme prévu
• Avant une version, je ne vérifie pas toutes les fonctionnalités manuellement pour confirmer que l'application fonctionne toujours,
• Je suis sûr que mon application est toujours stable à un certain niveau

Cependant, c'est un peu lié à moi puisque je ne suis vraiment pas prêt à "gérer plusieurs éléments à la fois". et "se concentrer". Par conséquent, les tests unitaires fonctionnent pour moi et me permettent littéralement de sauver ma journée, lorsque j'ai introduit une nouvelle fonctionnalité qui a cassé une ancienne fonctionnalité.

Si ce n’est pas le cas, ne l’utilisez pas. Si vous obtenez toujours le même résultat, les mêmes performances et la même qualité avec le même nombre de bogues, cela signifie que vous n'avez pas besoin de tests unitaires. Ou vous devez réviser vos méthodologies de tests unitaires.

P.S. Sur la base de votre taux de bogues et de ce que vous avez dit, vous parlez comme un génie (en supposant qu'il s'agisse de projets de moyenne ou grande envergure), je vous conseille donc de ne pas utiliser les tests unitaires, il semblerait que tout se passe bien pour vous. Mais pour le reste du monde qui n’est pas un génie comme moi, je recommande vivement Unit Test car cela a fonctionné pour moi.

Answer 14

Je ne vous connais pas, mais je viens de vérifier deux correctifs pour deux coredumps créés par des modifications de code existant prises en compte par mes tests unitaires. Et je venais d'avoir un problème de production majeur qui aurait été résolu par un test unitaire si j'avais davantage confiance en ses résultats (nos tests sont un peu plus fonctionnels que je ne voudrais l'admettre).

Answer 15

Il me semble que les tests unitaires formels avec les outils de test courants ressemblent beaucoup à la sécurité des aéroports américains.

• Cela donne l'illusion de sécurité
• Cela fait que les gens se sentent bien
• C'est très gênant (extrêmement gênant si vous avez la mauvaise couleur de peau)
• Les gens vous salueront du poing si vous le critiquez ...
• Ces mêmes personnes resteront confuses quand leur processus les échouera et elles sauteront dans le wagon du prochain groupe ...

Je pense que les gens ont des perspectives différentes sur les logiciels. À mon avis, le logiciel est un moyen de gagner de l'argent (en augmentant les revenus ou en réalisant des économies). J'ai vu les billets pour TDD, qui est le moyen le plus proche que je perçois comme une manière scientifique de répondre à la question, mais la méthodologie manque de rigueur scientifique. Aucun des articles spécifiés n’avait une méthode de base ou une méthode alternative assez contrastée.

Je suppose que les fans de tests unitaires formels continueront à se sentir en sécurité. Je continuerai à écrire mes spécifications sur un bout de papier et les placerai dans le bol aux pieds de ma statue de Saint-Antoine, en disant une prière. Qui peut dire quel moyen est le plus efficace, mais mon chemin est bon, je vais peut-être écrire un livre blanc à ce sujet.

Answer 16

N'oubliez pas la popularité croissante des coupes de cheveux et des vêtements des années 70 et 80 ... qui n'a pas si bien fonctionné pour ceux d'entre nous qui ont vécu ces décennies-là.

Les tests unitaires formels demandent beaucoup de travail et d’entretien. J'imagine que cela prend 20 à 50% du temps nécessaire au développement du logiciel. Ce que je demande, c’est le prix connu, qui consiste à ajouter des frais généraux de 20 à 50% à chaque effort de développement. Ce gain est notable et / ou prouvable.

En ne faisant pas de tests unitaires formels, vous obligez le développeur à réfléchir aux éléments appropriés à tester. Le développeur prend davantage possession du produit.

Les tests unitaires formels ressemblent à du jus de l'huile de serpent ... Tout le monde et son frère disent que c'est bon, utile, cool, etc., mais il n'y a pas eu d'essai contrôlé contrôlé randomisé pour prouver qu'il permet réellement de gagner du temps ou de l'argent. Jusqu'à présent, toutes les réponses sont des témoignages subjectifs.

Ce que j'aimerais savoir, c'est s'il existe un gestionnaire de logiciel capable de démontrer une productivité supérieure (voire une qualité supérieure) après l'introduction du test unitaire.

lol - le discours facétieux de S.Lott est la réponse la mieux classée ... Étant donné que ce forum est anonyme (pour moi en tout cas), votre respect n'est pas ce que je recherche. Je me considère à peine plus que médiocre. J'ai travaillé avec des développeurs exceptionnels. En général, ces gars-là ne font même pas de tests de base de leur code - ils savent simplement que cela fonctionnera.