Mesurer la couverture du code uniquement sur le nouveau code

Question

Nous cherchons une façon créative de mesurer la couverture de code sur un nouveau code distinct du code existant. Nous avons un grand projet hérité et voulons commencer à obtenir une couverture de 90% sur toute nouvelle fonctionnalité. Nous aimerions trouver un moyen de visualiser facilement un rapport qui filtre tout code plus ancien pour s'assurer que la nouvelle fonctionnalité répond à notre objectif. Il est évident que nous recherchons toujours une couverture globale croissante sur le projet, mais nous avons besoin d'une manière non-manuelle pour nous donner des commentaires sur la nouvelle activité de code. Nous avons ceci fonctionnant pour l'analyse statique puisque nous pouvons regarder les dates sur les dossiers de source. Comme Cobertura analyse les fichiers de classe, ils ont de nouvelles dates et cette technique ne fonctionne pas.

Des idées?

Stack:

Java 1.5 JUnit Cobertura Hudson

Answer 1

Jetez un oeil sur emma.sourceforge et associé plugin Eclipse here (si vous utilisez Eclipse)

Je pense que cet outil peut répondre à votre besoin en sélectionnant exactement ce qu'il faut tester pour la couverture.

Answer 2

Nous avions une situation similaire .. voulait un nouveau code testé, mais ne pouvait pas tester tous les anciens codes à la fois. Ce que nous avons fait n'est pas exactement ce que vous avez demandé, mais peut vous donner une idée.

Nous avons un fichier appelé linecoverage.standard, et un fichier appelé branchcoverage.standard qui se trouve sur le serveur de construction (et des copies locales). Ils ont un nombre à l'intérieur avec les limites de couverture de ligne et de branche en cours. Si le code enregistré est inférieur à la norme, la génération échoue. Si c'est à la norme, il passe la construction. S'il est au-dessus de la norme, une nouvelle norme est écrite égale à la couverture actuelle.

Cela signifie que notre couverture de code ne s'aggravera jamais, et devrait augmenter lentement. Si le nouveau code est de 90%, la couverture continuera à grimper. Vous pouvez également définir un objectif comme augmenter la norme de 1 chaque semaine jusqu'à ce qu'il atteigne votre objectif final (90%). Avoir à ajouter quelques tests par semaine à l'ancien code n'est pas une mauvaise idée, si elle est étalée sur assez de temps.

Notre couverture actuelle est jusqu'à 75% ish ... assez bon venant d'un taux de 0% il ya moins d'un an.

Answer 3

Je l'ai fait pour un grand projet C++ en utilisant svn blame combiné avec la sortie de gcov. Si vous compressez ces deux résultats ensemble, vous obtenez des informations de révision et des informations de couverture pour chaque ligne. J'ai effectivement chargé tout cela dans une base de données pour faire des requêtes (par exemple montrez-moi toutes les lignes non couvertes écrites par joe depuis r1234). Si vous voulez seulement un nombre agrégé, vous pouvez simplement éviter de compter les anciennes lignes non couvertes dans votre total.

Answer 4

IMO la meilleure option est de diviser la base de code en "nouvelles" et "anciennes" sections. Ensuite, exécutez l'analyse de couverture de test uniquement dans la "nouvelle" section ou ignorez les résultats pour la "vieille" section. Les deux meilleurs moyens d'y parvenir sont a) diviser le codebase en deux arborescences sources (deux projets avec une dépendance entre), ou b) maintenir deux hiérarchies de paquetages distinctes dans un même projet. Deux projets distincts sont probablement préférables, mais cela pourrait ne pas être possible s'il existe une dépendance cyclique entre la base de code héritée et la nouvelle base de code (l'ancien code dépend du nouveau code et le nouveau code dépend de l'ancien code). Si vous pouvez le gérer, une dépendance unidirectionnelle entre l'ancien et le nouveau code rendra également la base de code combinée plus facile à comprendre.

Une fois cela fait, ajustez cobertura pour qu'il analyse seulement les bits que vous voulez, ou du moins concentrez-vous simplement sur la "nouvelle" partie du code. Une astuce supplémentaire est que dans ce schéma, il est préférable de déplacer des morceaux de code de la section "legacy" vers la section "new" à mesure que vous refactorisez/ajoutez des tests (si le code bouge fréquemment dans l'autre direction, bien :-).

Answer 5

Nous l'avons fait comme ci-dessous en utilisant sonar.exclusions propriété: Nous utilisons Sonar pour afficher les rapports de couverture de code (signalé par Cobertura).

a) Identifiez les classes sur lesquelles vous ne voulez pas que le rapport de couverture apparaisse (Classes héritées) Utilisez votre client de ligne cmd SCM. par exemple: fichiers p4 // depot/... @ 2000/01/01, @ 2013/07/13 git log --until = "5 jours"

cette liste directe dans un fichier. Vous devrez effectuer une analyse basée sur l'outil SCM que vous utilisez et votre fichier de destination devrait contenir un nom de fichier par ligne. B) Maintenant, lorsque vous intégrez à Sonar (à partir de Jenkins Job), utilisez la propriété ci-dessous.

-Dsonar.exclusions=<filename> 

Et votre rapport de couverture finale Sonar ne contient que vos nouvelles classes (ajouté après 07/13 dans l'exemple ci-dessus).