Je suis curieux de savoir quelle valeur raisonnable / typique est destiné au rapport de code de test du code de production lorsque les gens font TDD. En regardant un composant, j'ai 530 lignes de code de test pour 130 lignes de code de production. Un autre composant comporte 1000 lignes de code de test pour 360 lignes de code de production. Les tests d'unités nécessitent donc environ 3x à 5 fois autant de code. Ceci est pour le code JavaScript. Je n'ai pas beaucoup testé C # code pratique, mais je pense qu'un autre projet, je cherchais 2x à 3 fois autant de code de test, puis code de production.
Il me semblerait que plus la valeur est inférieure, en supposant que les tests soient suffisants, refléteraient des tests de qualité supérieure. Spéculation pure, je me demande simplement quels ratios d'autres personnes voient.
Je sais que les lignes de code sont une métrique lâche, mais car je code dans le même style pour le test et la production (même format d'espacement, même nombre de commentaires, etc.), les valeurs sont comparables.
5 Réponses :
Cela dépendra vraiment de la manière dont les choses sont prises en compte, mais à mon expérience (oui, j'ai mesuré cela sur certains projets), j'ai vu des ratios de 2: 1 à 5: 1 (ceci est pour le code testé de cours). Regardez également le ProductionCodevsunittestSratio et UnittestTocoderatio pages sur le wiki C2.
Ces chiffres sonnent normal. Le test unitaire le plus long que j'ai écrit était plus de 1500 lignes et il n'a teséré que 300 lignes de code.
@CallumBradbury Une unité est la plus petite quantité de code que vous puissiez effectuer facilement pour tester. 300 lignes sont trop grandes et devraient être refactées alors lorsque j'ai été remis le code, j'ai écrit des tests pour cela afin qu'il puisse être brisé en toute sécurité.
WOW, ces chiffres sont assez grands! Je suis d'environ 1: 1, parfois pour les classes qui ont une complexité cyclomatique plus élevée, elle peut aller plus près de 2: 1 en faveur des tests d'unité LOC, mais qui définit des cloches d'alarme que la classe a besoin de refactoring.
Vous mentionnez que vous utilisez le même style pour vos tests unitaires. C'est bien en ce qui concerne vos tests comme code de production, mais avez-vous vraiment besoin de beaucoup de commentaires pour le code de test? Nommez-vous vos méthodes de test afin qu'elles soient descriptives de ce que le test affirme? Par exemple, en utilisant la fonction «Compteyxwhenythenythenz», la nommée, il convient de ne pas préciser ce que le test ne fonctionne pas sans une grande section de commentaires.
Avez-vous refactore vos tests? déplacer toute duplication de la configuration, etc. en méthodes distinctes?
Gardez-vous des tests de votre unité simples afin de ne pas affirmer qu'une chose par test?
Et tu tests excessivement des choses comme getters / setters?
J'ai dit que mon utilisation de commentaires est cohérente entre la production et le code de test - mais cela signifie pas beaucoup de commentaires du tout;)
Juste curieux de quelle langue vous utilisez où vous voyez un ratio 1: 1? Je pense que mes tests en JavaScript peuvent être plus lourds car je fais plus de gaspillage puis se moquer par rapport à mon code C #.
Différentes langues et cadres de test seront très différents. Par exemple, BDD frameworks beaucoup "sèche-linge" que le code de style de testUnit. En outre, sur quelques projets, j'ai fini par avoir de très gros ensembles de données alimentés à seulement quelques lignes de Java-- qui ont testé des milliers de lignes du code-- afin que mon rapport soit tout à fait vissé.
Je viens de regarder mes trois projets les plus récents (rails de taille moyenne), et le code aux rapports de test était de 1: 2,3, 1: 1,6 et 1: 1.9 ... Donc, vous avez des numéros comme ils sont similaires. (Je viens de courir Quoi qu'il en soit, des signes d'avertissement que vous avez trop de tests:
Statistiques Rake - Je ne les ai jamais vraiment regardées avant.)
J'utilise personnellement une affirmation du rapport local. Certaines choses peuvent nécessiter plus de maquette et de configurer le code de configuration que d'autres. Je sens que les lignes X du code de test à Y Les lignes de code Prod peuvent ne pas être super utiles. Un outil de couverture de code est probablement le meilleur moyen de le regarder. J'ai trouvé sur mes deux derniers projets mon code a 1 assert pour 10 lignes de code de production. Est-ce que quelqu'un d'autre obtient des valeurs similaires?
BTW, cela ressemble vraiment à une discussion, pas une vraie question.