combien de temps passez-vous sur les tests unitaires?

27

Dans une entreprise pour laquelle je travaillais auparavant, les dirigeants ont insisté sur le fait que la couverture du code avec les tests unitaires doit être de 99% ou plus. Cela a entraîné l'écriture de plus de tests que de code. Il nous a fallu littéralement 3 jours pour écrire des tests pour une seule classe qui ont pris une journée à mettre en œuvre.

En conséquence, cependant, j'ai beaucoup appris sur le TDD, les outils de test, les pratiques, etc.

Dans l'entreprise pour laquelle j'ai travaillé par la suite, les tests unitaires étaient une chose inconnue. C'était quelque chose que quelqu'un avait peut-être entendu auparavant. J'ai eu du mal à leur présenter le concept de test unitaire, mais sans effet.

Maintenant, en tant que travailleur indépendant, je me demande - combien de temps faut-il vraiment consacrer aux tests unitaires? Étant principalement développeur iPhone / Android, quelles parties du code devraient être couvertes par les tests?

— Maggie
source

Dans mon entreprise précédente, c'était Java EE, framework stripes and struts. Comme je l'ai dit, il s'agit désormais principalement du développement iPhone et Android.

— Maggie

TDD signifie que vous écrivez les tests avant le code. Il semble que ce soit un test "après coup", ce qui est autre chose.

les managers ne se souciaient pas de la technique, mon chef d'équipe insistait sur le TDD. cela a fini par une combinaison des deux :)

— Maggie

Maggie, vous pourriez trouver cet article intéressant: fastcompany.com/magazine/06/writestuff.html

Existe-t-il des métrologies pour estimer le temps? Outils pour le code JS / .NET?

— hellboy

16

La quantité de tests unitaires nécessaires dépend de plusieurs facteurs:

Taille du produit (plus le projet est grand, plus il est nécessaire d'inclure au moins certains tests unitaires)
Niveau de qualité requis (si vous assemblez rapidement un logiciel qui doit être sorti le plus rapidement possible et que quelques bugs mineurs sont acceptables, alors vous pourriez être obligé de sauter certains tests comme les tests unitaires)
Type de produit (les interfaces utilisateur peuvent être testées unitairement, mais il est parfois plus facile de sauter les tests unitaires sur les sections GUI lourdes d'un projet et de les tester manuellement à la place)
Votre capacité / historique de codage (Quel type de bogues créez-vous normalement? S'agit-il de choses que les tests unitaires attrapent normalement ou de choses qu'un autre type de tests trouve normalement. Le savoir pourrait vous pousser à faire plus ou moins de tests unitaires)

— jzd
source

10

Dans notre groupe de produits, nous visons une couverture de code de 50 à 70% pour les tests unitaires et une couverture de 90% + pour les tests unitaires et l'automatisation des tests combinés. Le temps typique consacré à l'écriture des tests unitaires est d'environ 1 jour pour chaque fonctionnalité nécessitant 3-4 jours de codage tête en bas. Mais cela peut varier avec de nombreux facteurs.

La couverture du code à 99% est excellente. Les tests unitaires sont excellents. Mais une couverture de code de 99% à partir des tests unitaires seuls? J'ai du mal à croire que vous pouvez obtenir autant de couverture grâce aux tests unitaires .

Pour le cas où vous avez passé 3 jours à écrire des tests pour une classe qui, autrement, mettait 1 jour à mettre en œuvre. Vous n'avez pas expliqué pourquoi cela a pris autant de temps ou partagé un code. D'après les spéculations, je suppose que vous n'écriviez pas vraiment un véritable test unitaire pour votre classe, mais que vous écriviez en fait automatisation des tests . Et il n'y a rien de mal à cela - tant que vous reconnaissez la différence entre les deux différents types de tests.

Mais vous avez dit que les trois jours de rédaction du test ne concernaient qu'une seule classe. Peut-être que la classe elle-même n'a pas été conçue pour les tests unitaires. La classe implémente-t-elle l'interface utilisateur? La mise en réseau? E / S de fichier? Si c'est le cas, vous pourriez avoir fini par écrire plus de code pour tester le runtime Java que votre logique métier qui interagit avec le runtime.

TDD vous fait réfléchir en termes d'interfaces et d'interfaces vers les dépendances. Cette classe unique qui implémente l'interface utilisateur, la mise en réseau et le fichier / io pour une seule fonctionnalité pourrait être mieux servie divisée en plusieurs classes - une pour la mise en réseau, une pour le fichier / io et l'interface utilisateur divisée en une conception de contrôleur de visionneuse de modèle. Ensuite, vous pouvez implémenter des tests appropriés pour chacun avec des objets simulés simples pour les dépendances. Bien sûr, tout cela prend plus de temps. Ainsi, plutôt que 1 jour pour coder et 3 jours pour écrire des tests, ce type de conception peut nécessiter 3 jours de codage et 1 jour de tests d'écriture. Mais le code sera bien mieux maintenable et réutilisable.

— selbie
source

1

Très bonne réponse. La plupart était trop compliqué pour les tests, vous avez raison. Et diviser la classe en plusieurs unités plus petites juste pour convenir à de meilleurs tests unitaires semble un peu exagéré. J'adorerais joindre le code de la classe et des tests d'accompagnement, et j'aimerais entendre votre opinion, mais je ne sais pas si je suis autorisé à le faire. Le code n'est pas strictement le mien, et je ne travaille plus pour cette entreprise, donc je voudrais éviter les ennuis.

— Maggie

2

C'est pourquoi vous devez d'abord écrire les tests. Ensuite, vous pouvez trouver les endroits naturels où la logique se colle.

10

Les tests unitaires portent leurs fruits au moment de la maintenance. Si vous prévoyez d'avoir une application longue durée, vous passerez plus de temps à maintenir que vous ne le pensez maintenant (si vous ne l'avez pas encore essayé, vous serez surpris de la durée de vie d'un projet réussi)

Ce que vous voulez, c'est que si vous modifiez accidentellement vos fonctionnalités, vos tests échouent afin que vous trouviez ces choses le plus rapidement possible. Les clients n'aiment pas beaucoup quand les fonctionnalités changent de façon inattendue.

3

Et vous regardez mal quand vous corrigez le bogue A uniquement pour introduire les bogues B & C.

— JeffO

dépend si B et C sont capturés par des tests ou non

"vous passerez plus de temps à entretenir que vous ne le pensez maintenant" - en effet, surtout en tenant compte du fait que les produits SW survivent généralement à leur durée de vie prévue, souvent de loin.

— Péter Török

Vous ne pouvez pas vraiment "planifier" d'avoir une application longue durée puisque vous ne pouvez pas dire à l'avance si le projet réussira ou non. Vous devriez toujours considérer cela lors de la budgétisation du temps pour les tests

— Eran Galperin

1

@Eran, vous devez donc planifier l'échec afin de ne pas avoir de budget pour les tests?

4

Si vous faites TDD, vous écrirez les tests en même temps que le code, en basculant entre eux toutes les quelques minutes (ou moins). Il n'y aura pas de temps distinct passé pour les tests. L'utilisation de TDD permet de savoir beaucoup plus facilement que votre couverture de test est solide.

Si vous effectuez des tests unitaires après coup, vous devez écrire les tests qui vous diront si le code est cassé en raison de modifications. Je ne compterais pas sur les mesures de couverture ici, mais j'irais en fonction des cas d'utilisation et des paramètres vers les interfaces publiques. Cela sera finalement basé sur votre bon goût et votre expérience.

— Sean McMillan
source

Oui, pour moi, cela est vrai (en fait, je passe généralement du travail aux tests au travail sur le code produit toutes les quelques secondes , pas toutes les minutes.) Je travaille donc sans doute sur des tests 100% du temps.

— Jonathan Hartley

2

Si vous ne passez pas de temps sur les tests, vous passerez encore plus de temps à déboguer en code live.
Passez donc autant de temps que nécessaire aux tests, pour couvrir tout (ou 99% du code).

— OZ_
source

4

Pourquoi les gens ont-ils une telle paranoïa de débogage? Si vous connaissez les outils, vous rencontrez rarement un problème qui prend plus de 5 minutes à déboguer. Les problèmes difficiles à déboguer sont principalement liés au threading, mais les tests unitaires sont de toute façon inutiles.

— Coder

3

@Coder, parce que les gens ont de l'expérience et savent que les tests sont beaucoup plus utiles que le débogage aveugle.

— OZ_

2

Dépend. Les tests unitaires sont souvent contre-productifs et ajoutent un faux sentiment de sécurité. Et dans un code bien structuré, vous n'aurez pas de problème de "débogage aveugle". Vous avez un problème, vous savez où chercher. Si vous ne le faites pas, faites une revue complète du code / design. Voir également: programmers.stackexchange.com/questions/86636/…

— Coder

4

C'est le problème avec de nombreux partisans de TDD, ils ont une position hostile contre le débogage et la conception, tout en s'appuyant sur des tests pour trouver tous les bogues. Ensuite, dans le code de production, les applications fuient la mémoire, les poignées et se bloquent sur plusieurs cœurs, et elles sont comme? WTH ?. TDD n'est qu'un outil et, selon la tâche à accomplir, il peut être très productif ou très contre-productif. Essayez d'écrire des tests unitaires pour tous les cas difficiles dans la publication liée, et vous ne livrerez jamais le produit.

— Codeur

1

"Si vous connaissez les outils, vous rencontrez rarement un problème qui prend plus de 5 minutes à déboguer." - @Coder Je me demande quel type d'applications vous regardez.

— Kirk Broadhurst

2

Comme d'autres l'ont déjà noté, cela dépend en grande partie du type de logiciel. Le rapport de temps de test / développement de 3: 1 que vous mentionnez peut être un peu trop pour les projets moyens, mais peut être parfaitement OK pour les applications critiques et peut-être même trop peu pour un système vital.

Une couverture de test unitaire de 99 +% est de même peut-être trop à attendre dans le cas d'une application moyenne, mais trop peu pour un projet critique.

D'après mon expérience, étant donné qu'une partie importante du code de production est un code de gestion des erreurs, une couverture de 80 à 90% serait suffisante pour la plupart des applications, et cela pourrait nécessiter à peu près le même temps passé à écrire des tests unitaires que le code de production. (Là encore, si l'on travaille sérieusement à la mode TDD, les deux sont complètement entrelacés pour devenir pratiquement une seule tâche, donc on ne peut qu'évaluer le rapport réel.)

— Péter Török
source

avez-vous de l'expérience dans les applications mobiles? quel serait un rapport test / développement acceptable pour une application mobile simple?

— Maggie

@Maggie, malheureusement non. (Donc, si j'avais besoin d'en écrire un, je dépenserais probablement plus que mon temps habituel pour les tests unitaires :-)

— Péter Török