Tous les outils / suggestions sur la façon de réfuter l'argument de la qualité de la couverture du code

Maintenant, je sais que les gens pourraient considérer cette question en double ou posée plusieurs fois, auquel cas j'apprécierais un lien vers des questions pertinentes avec une réponse à ma question.

J'ai récemment été en désaccord avec certaines personnes sur la couverture du code. J'ai un groupe de personnes qui souhaitent que notre équipe abandonne la recherche de la couverture de code en se basant sur l'argument selon lequel une couverture à 100% ne signifie pas des tests de bonne qualité et donc un code de bonne qualité.

J'ai pu repousser en vendant l'argument selon lequel la couverture du code me dit ce qui n'a pas été testé avec certitude et nous aide à nous concentrer sur ces domaines.

(Ce qui précède a été discuté de manière similaire dans d'autres questions SO comme celle-ci - /programming/695811/pitfalls-of-code-coverage )

L'argument de ces gens est - alors l'équipe réagirait en créant rapidement des tests de faible qualité et perdrait ainsi du temps sans ajouter de qualité significative.

Bien que je comprenne leur point de vue, je cherche un moyen de plaider en faveur d'une couverture de code plus solide en introduisant des outils / cadres plus robustes qui prennent en charge davantage de critères de couverture(Functional, Statement,Decision, Branch, Condition, State, LCSAJ, path, jump path, entry/exit, Loop, Parameter Value etc) .

Ce que je recherche, c'est une suggestion pour une combinaison de tels outils de couverture de code et de pratiques / processus pour les accompagner, ce qui peut m'aider à contrer ces arguments tout en étant à l'aise avec ma recommandation.

Je serais également heureux de recevoir tout commentaire / suggestion d'accompagnement basé sur votre expérience / vos connaissances sur la façon de contrer un tel argument, car bien que subjective, la couverture du code a aidé mon équipe à être plus consciente de la qualité du code et de la valeur des tests.

Edit: Pour réduire toute confusion sur ma compréhension de la faiblesse de la couverture de code typique, je tiens à souligner que je ne fais pas référence aux Statement Coverage (ou aux lignes de code exécutées) des outils (il y en a beaucoup). En fait, voici un bon article sur tout ce qui ne va pas: http://www.bullseye.com/statementCoverage.html

Je cherchais plus qu'une simple couverture de relevé ou de ligne, allant plus dans plusieurs critères et niveaux de couverture.

Voir: http://en.wikipedia.org/wiki/Code_coverage#Coverage_criteria

L'idée est que si un outil peut nous dire notre couverture basée sur plusieurs critères, cela devient une évaluation automatisée raisonnable de la qualité du test. Je n'essaie nullement de dire que la couverture de ligne est une bonne évaluation. En fait, c'est la prémisse de ma question.

Edit:
Ok, peut-être que je l'ai projeté un peu trop dramatiquement, mais vous comprenez. Le problème consiste à définir les processus / politiques en général dans toutes les équipes de manière homogène / cohérente. Et la crainte est générale de savoir comment garantir la qualité des tests, comment allouer le temps garanti sans avoir aucune mesure à lui. Ainsi, j'aime avoir une fonctionnalité mesurable qui, lorsqu'elle est sauvegardée avec des processus appropriés et les bons outils, nous permettrait d'améliorer la qualité du code tout en sachant que le temps n'est pas forcé de passer dans des processus inutiles.

EDIT: Jusqu'à présent, ce que j'ai des réponses:

• Les revues de code devraient couvrir les tests pour garantir la qualité des tests
• La stratégie Test First permet d'éviter les tests écrits après coup pour simplement augmenter la couverture%
• Explorer des outils alternatifs couvrant des critères de test autres que simplement Statement / Line
• L'analyse du code couvert / du nombre de bogues trouvés aiderait à apprécier l'importance de la couverture et à améliorer la situation
• Plus important encore, faites confiance à la contribution de l'équipe pour faire ce qu'il faut et lutter pour leurs convictions
• Blocs couverts / # de tests - Discutable mais détient une certaine valeur

Merci pour les réponses impressionnantes jusqu'à présent. Je les apprécie vraiment. Ce fil est meilleur que des heures de brainstorming avec les pouvoirs en place.

D'après mon expérience, la couverture du code est aussi utile que vous le faites . Si vous écrivez de bons tests qui couvrent tous vos cas, réussir ces tests signifie que vous avez satisfait à vos exigences. En fait, c'est exactement l' idée qu'utilise le développement piloté par les tests . Vous écrivez les tests avant le code sans rien savoir de l'implémentation (Parfois, cela signifie qu'une autre équipe écrit entièrement les tests). Ces tests sont configurés pour vérifier que le produit final fait tout ce que vos spécifications disent qu'il a fait, et ALORS vous écrivez le code minimum pour passer ces tests.

Le problème ici, évidemment, est que si vos tests ne sont pas assez forts, vous manquerez des cas de bord ou des problèmes imprévus et écrivez du code qui ne correspond pas vraiment à vos spécifications. Si vous êtes vraiment déterminé à utiliser des tests pour vérifier votre code, alors écrire de bons tests est une nécessité absolue, ou vous perdez vraiment votre temps.

Je voulais modifier la réponse ici car j'ai réalisé qu'elle ne répondait pas vraiment à votre question. Je regarderais cet article wiki pour voir certains avantages déclarés du TDD. Cela dépend vraiment de la façon dont votre organisation fonctionne le mieux, mais TDD est certainement quelque chose qui est utilisé dans l'industrie.

Tout d' abord, les gens font la couverture de l' avocat 100%:

La plupart des développeurs considèrent que "la couverture des déclarations à 100%" est adéquate. C'est un bon début, mais à peine suffisant. Un meilleur identifiant standard de couverture pour répondre à ce qu'on appelle la «couverture de 100% des succursales», ...

Steve McConnell, Code Complete , Chapter 22: Developer Testing.

Comme vous l'avez mentionné, vous et d'autres, la couverture du code pour le seul fait de la couverture ne devrait pas accomplir grand-chose. Mais si vous ne pouvez pas exécuter une ligne de code, pourquoi est-elle écrite?

Je suggère de résoudre l'argument en collectant et en analysant les données de vos propres projets.

Pour collecter les données, j'utilise personnellement les outils suivants:

• JaCoCo et le plug-in Eclipse associé EclEmma pour mesurer la couverture du code.
• Scripts Ant pour la construction, les tests et les rapports automatisés.
• Jenkins pour les builds continus - tout changement de contrôle de source déclenche une build automatique
• Plugin JaCoCo pour Jenkins - capture les mesures de couverture pour chaque build et les tendances graphiques. Permet également de définir des seuils de couverture par projet qui affectent la santé de la construction.
• Bugzilla pour le suivi des bugs.

Une fois que vous avez cela (ou quelque chose de similaire) en place, vous pouvez commencer à regarder de plus près vos propres données:

• trouve-t-on plus de bogues dans les projets mal couverts?
• y a-t-il plus de bogues dans les classes / méthodes mal couvertes?
• etc.

Je pense que vos données seront en charge votre position sur la couverture de code; c'est certainement mon expérience. Si ce n'est pas le cas, cependant, votre organisation peut réussir avec des normes de couverture de code plus faibles que vous ne le souhaiteriez. Ou peut-être que vos tests ne sont pas très bons. Nous espérons que la tâche concentrera les efforts sur la production de logiciels avec moins de défauts, quelle que soit la résolution du désaccord de couverture de code.

L'argument de ces gens est que l' équipe réagirait en créant rapidement des tests de faible qualité et perdrait ainsi du temps sans ajouter de qualité significative.

C'est une question de confiance , pas d' outils .

Demandez-leur pourquoi, s'ils croient vraiment à cette affirmation, ils feraient confiance à l'équipe pour écrire du code?

Ok, peut-être que je l'ai projeté un peu trop dramatiquement, mais vous comprenez. Le problème consiste à définir les processus / politiques en général dans toutes les équipes de manière homogène / cohérente.

Je pense que c'est ça le problème. Les développeurs ne se soucient pas (et souvent pour d'excellentes raisons) de politiques cohérentes ou globales, et veulent la liberté de faire ce qu'ils pensent être juste plutôt que de se conformer aux politiques d'entreprise.

Ce qui est raisonnable à moins que vous ne prouviez que les processus et mesures mondiaux ont une valeur et un effet positif sur la qualité et la vitesse de développement.

Chronologie habituelle:

1. dev: hé, regardez - j'ai ajouté des mesures de couverture de code à notre tableau de bord, n'est-ce pas génial?
2. gestionnaire: bien sûr, ajoutons des objectifs obligatoires et la conformité à ceux
3. dev: peu importe, la couverture du code est stupide et inutile, laissons tomber

D'après mon expérience, il y a quelques choses à combiner avec la couverture du code pour que la métrique en vaille la peine:

Revues de code

Si vous pouvez renvoyer les mauvais tests au développeur, cela peut aider à limiter le nombre de mauvais tests qui fournissent cette couverture insignifiante.

Suivi des bogues

Si vous avez un tas de couverture de code sur un module, mais que vous obtenez toujours de nombreux bogues graves dans ce domaine, cela peut indiquer un problème où ce développeur doit être amélioré avec ses tests.

Pragmatisme

Personne n'arrivera à 100% avec de bons tests sur du code non trivial. Si vous, en tant que chef d'équipe, regardez la couverture du code, mais au lieu de dire "nous devons atteindre N%!" vous identifiez les lacunes et demandez aux gens "d'améliorer la couverture dans le module X" qui atteint votre objectif sans donner aux gens l'occasion de jouer le système.

Blocs couverts / nombre de tests

La plupart des outils de couverture de code répertorient les blocs couverts par rapport aux blocs non couverts. La combinaison de cela avec un certain nombre de tests réels vous permet d'obtenir une métrique indiquant à quel point les tests sont «larges», indiquant soit de mauvais tests, soit une conception couplée. Ceci est plus utile en tant que delta d'un sprint à un autre, mais l'idée est la même - combinez la couverture du code avec d'autres mesures pour obtenir plus d'informations.

Voici mes 2 cents.

Il existe de nombreuses pratiques qui ont reçu beaucoup d'attention récemment, car elles peuvent apporter des avantages au développement de logiciels. Cependant, certains développeurs appliquent ces pratiques à l'aveuglette: ils sont convaincus que l'application d'une méthodologie revient à exécuter un algorithme et qu'après avoir effectué les étapes correctes, on devrait obtenir le résultat souhaité.

Quelques exemples:

• Écrivez des tests unitaires avec une couverture de code à 100% et vous obtiendrez une meilleure qualité de code.
• Appliquez TDD systématiquement et vous obtiendrez une meilleure conception.
• Faites la programmation par paires et vous améliorerez la qualité du code et réduirez le temps de développement.

Je pense que le problème de base avec les déclarations ci-dessus est que les humains ne sont pas des ordinateurs et que l'écriture de logiciels n'est pas comme l'exécution d'un algorithme.

Ainsi, les déclarations ci-dessus contiennent un peu de vérité mais simplifient un peu trop les choses, par exemple:

• Les tests unitaires détectent de nombreuses erreurs et la couverture du code indique quelles parties du code sont testées, mais tester des choses triviales est inutile. Par exemple, si en cliquant sur un bouton la boîte de dialogue correspondante s'ouvre, toute la logique envoyant l'événement bouton au composant qui ouvre la boîte de dialogue peut être testée par un simple test manuel (cliquez sur le bouton): est-ce rentable à l'unité tester cette logique?
• Bien que TDD soit un bon outil de conception, il ne fonctionne pas bien si le développeur a une mauvaise compréhension du domaine problématique (voir par exemple ce fameux article ).
• La programmation par paires est efficace si deux développeurs peuvent travailler ensemble, sinon c'est un désastre. En outre, les développeurs expérimentés peuvent préférer discuter brièvement des problèmes les plus importants, puis coder séparément: passer de nombreuses heures à discuter de nombreux détails qu'ils connaissent déjà peut être à la fois ennuyeux et une grande perte de temps.

Revenons à la couverture du code.

J'ai pu repousser en vendant l'argument selon lequel la couverture du code me dit ce qui n'a pas été testé avec certitude et nous aide à nous concentrer sur ces domaines.

Je pense que vous devez juger au cas par cas s'il vaut la peine d'avoir une couverture à 100% pour un certain module.

Le module effectue-t-il des calculs très importants et compliqués? Ensuite, je voudrais tester chaque ligne de code, mais aussi écrire des tests unitaires significatifs (tests unitaires qui ont du sens dans ce domaine).

Le module effectue-t-il une tâche importante mais simple comme ouvrir une fenêtre d'aide en cliquant sur un bouton? Un test manuel sera probablement plus efficace.

L'argument de ces gens est - alors l'équipe réagirait en créant rapidement des tests de faible qualité et perdrait ainsi du temps sans ajouter de qualité significative.

À mon avis, ils ont raison: vous ne pouvez pas appliquer la qualité du code en exigeant uniquement une couverture de code à 100%. L'ajout de plus d'outils pour calculer la couverture et faire des statistiques n'aidera pas non plus. Au lieu de cela, vous devriez discuter des parties du code qui sont plus sensibles et qui devraient être testées de manière approfondie et lesquelles sont moins sujettes aux erreurs (dans le sens où une erreur peut être découverte et corrigée beaucoup plus facilement sans utiliser de tests unitaires).

Si vous poussez la couverture de code à 100% sur les développeurs, certains commenceront à écrire des tests unitaires idiots pour remplir leurs obligations au lieu d'essayer d'écrire des tests raisonnables.

comment allouez-vous du temps garanti sans avoir aucune mesure à lui

C'est peut-être une illusion que vous pouvez mesurer l'intelligence et le jugement humains. Si vous avez des collègues compétents et que vous faites confiance à leur jugement, vous pouvez accepter quand ils vous disent "pour ce module, l'augmentation de la couverture du code apportera très peu d'avantages. autant de couverture que possible, nous avons besoin d'une semaine supplémentaire pour mettre en œuvre des tests unitaires raisonnables. ".

Donc (encore une fois, ce sont mes 2 cents): n'essayez pas de trouver un processus et de définir des paramètres tels que la couverture de code qui doivent s'adapter à toutes les équipes, pour tous les projets et pour tous les modules. Trouver un tel processus général est une illusion et je pense que lorsque vous en aurez trouvé un, il sera sous-optimal.

"l'équipe réagirait en créant rapidement des tests de faible qualité et donc perdrait du temps sans ajouter de qualité significative"

C'est un vrai risque, pas seulement théorique.

L'excédent de code seul est une métrique dysfonctionnelle. J'ai appris cette leçon de manière difficile. Une fois, je l'ai souligné sans la disponibilité de métriques ou de pratiques d'équilibrage. Des centaines de tests qui détectent et masquent les exceptions, et sans assertions, c'est une chose laide.

"suggestion pour une combinaison de ces outils de couverture de code et pratiques / processus pour les accompagner"

En plus de toutes les autres suggestions, il existe une technique d'automatisation qui peut évaluer la qualité des tests: les tests de mutation ( http://en.wikipedia.org/wiki/Mutation_testing ). Pour le code Java, PIT ( http://pitest.org/ ) fonctionne, et c'est le premier outil de test de mutation que j'ai rencontré.

Comme vous le constatez, le manque de couverture de code est facilement identifiable comme un risque de qualité logicielle. J'enseigne que la couverture du code est une condition nécessaire, mais insuffisante, pour la qualité du logiciel. Nous devons adopter une approche de tableau de bord équilibré pour gérer la qualité des logiciels.

La couverture du code n'est certainement pas la preuve de bons tests unitaires, en ce sens qu'ils sont corrects.

Mais à moins qu'ils ne puissent fournir un moyen de prouver que tous les tests unitaires sont bons (quelle que soit la définition du bien qu'ils peuvent proposer), c'est vraiment un point muet.

J'ai toujours trouvé que la couverture du code est facilement sensible à l' effet Hawthorne . Cela m'a amené à demander "pourquoi avons-nous des mesures logicielles?" et la réponse est généralement de fournir une compréhension de haut niveau de l'état actuel du projet, des choses comme:

"jusqu'où devons-nous faire?"

"quelle est la qualité de ce système?"

"Dans quelle mesure ces modules sont-ils compliqués?"

Hélas, il n'y aura jamais une seule métrique qui puisse vous dire à quel point le projet est bon ou mauvais, et toute tentative de dériver cette signification à partir d'un seul numéro sera nécessairement simplifiée. Bien que les métriques concernent toutes les données, interpréter ce qu'elles signifient est une tâche beaucoup plus émotionnelle / psychologique et en tant que telle ne peut probablement pas être appliquée de manière générique à des équipes de composition différente ou à des problèmes de différents domaines.

Dans le cas de la couverture, je pense qu'elle est souvent utilisée comme un proxy pour la qualité du code, albiet brut. Et le vrai problème est qu'il se résume à un sujet terriblement compliqué en un seul entier entre 0 et 100 qui sera bien sûr utilisé pour conduire un travail potentiellement inutile dans une quête sans fin pour atteindre une couverture à 100%. Des gens comme Bob Martin diront que la couverture à 100% est le seul objectif sérieux, et je peux comprendre pourquoi il en est ainsi, car tout le reste semble arbitraire.

Bien sûr, il existe de nombreuses façons d'obtenir une couverture qui ne m'aident pas vraiment à comprendre la base de code - par exemple, est-il utile de tester toString ()? qu'en est-il des getters et setters pour les objets immuables? Une équipe n'a que trop d'efforts à appliquer dans un temps fixe et ce temps semble toujours être inférieur au temps nécessaire pour faire un travail parfait, donc en l'absence d'un calendrier parfait, nous devons nous contenter d'approximations.

Une métrique que j'ai trouvée utile pour faire de bonnes approximations est Crap4J . Il est maintenant disparu mais vous pouvez facilement le porter / l'implémenter vous-même. Crap4J tente de relier la couverture de code à la complexité cyclomatique en impliquant que le code qui est plus compliqué (ifs, whiles, fors etc.) devrait avoir une couverture de test plus élevée. Pour moi, cette idée simple était vraiment vraie. Je veux comprendre où il y a des risques dans ma base de code, et un risque vraiment important est la complexité. Donc, en utilisant cet outil, je peux rapidement évaluer le niveau de risque de ma base de code. Si c'est compliqué, il vaut mieux augmenter la couverture. Si ce n'est pas le cas, je n'ai pas besoin de perdre du temps à essayer de couvrir chaque ligne de code.

Bien sûr, ce n'est qu'une métrique et YMMV. Vous devez passer du temps avec elle pour comprendre si cela aura du sens pour vous et si cela donnera à votre équipe une idée raisonnablement compréhensible de l'état d'avancement du projet.

Je ne dirais pas que revenir en arrière et couvrir le code existant est la meilleure voie à suivre. Je dirais qu'il est logique d'écrire des tests de couverture pour tout nouveau code que vous écrivez et / ou tout code que vous modifiez.

Lorsque des bogues sont trouvés, écrivez un test qui échoue à cause de ce bogue et corrigez le bogue pour que le test devienne vert. Mettez dans les commentaires du test pour quel bug il est écrit.

L'objectif est d'avoir suffisamment confiance en vos tests pour pouvoir apporter des modifications sans se soucier des effets secondaires inattendus. Consultez Travailler efficacement avec le code hérité pour un bon résumé des approches pour apprivoiser le code non testé.