2017-05-26 1 views
2

J'ai créé un scénario simple avec sources, tests et configuration. Je ne suis pas en mesure de faire en sorte que mon installation atteigne 100% de couverture de code dans Sonar, même si elle devrait l'être. (Lien vers référentiel avec les sources - https://bitbucket.org/sloukam/gradle-multiproject-coverage-sonar/src)Impossible d'atteindre 100% de couverture de code dans le sonar pour mon multiprojet graduel + java + groovy + trèfle + sonarqube

  • Il est un peu compliqué - il est multi-projets qui Gradle sources et des tests mélangés en java et groovy. Les tests sont dans le même module que la classe source et sont parfois testés dans le module de test "général" (appelons-le module de test d'intégration) et les sources correspondantes se trouvent dans leur module (dans ce cas simple module_module_one et source_module_two
  • Certaines sources sont écrites en Java et couvertes par le test routinier et vice versa.

Après avoir passé beaucoup de temps, je ne suis pas en mesure de voir dans mon locale Sonar 100% de couverture de code. Je voudrais vraiment apprécier aider à atteindre la cible de 100% de couverture de code Est-il possible avec ma structure de projet? Avec tout autre plugin de couverture?

Répondre

2

Tout d'abord, vous devriez certainement reconsidérer avoir des tests dans le même répertoire que les sources. Juste pour l'avenir, je séparerais les tests dans un autre répertoire. En outre, si vos tests sont dans vos sources, ils seront comptés comme fichiers source. Vous aurez donc besoin d'avoir des tests de vos tests, et un test de vos tests-tests, ... ad infinitum. Au-delà de cela, cependant, 100% de couverture est une quête du Graal. Se tenir à des normes élevées est une bonne chose, mais à un certain point, vous atteignez la loi des rendements décroissants. Au lieu de cela, je fixerais l'exigence à ... 90%? 92%? 95%?

+1

100%? C'est une quête du Saint Graal Batman! –

+0

100% de couverture - Je voudrais dire que toutes les classes de démonstration sont couvertes par des tests donc je m'attends à 100% de couverture dans cette attente de cas de démo. Dans un vrai projet, c'est comme si tu écrivais. – slon

+0

Pourquoi les tests ne se trouvent pas dans le même dossier/module que la classe source? Parce que dans ce cas les tests sont vraiment simples mais dans notre cas réel un test (intégration) couvre/teste plus de classes de différents modules. Ce cas de démo stupide est juste pour voir quelles classes semblent être découvertes par le test.Test de combinaison java-groovy (versa-versa) dans un module différent du fichier source ... combinaison de ces ... – slon

1
  • En gros, ce que nous résolvons ici est un scénario typique de tests unitaires/tests d'intégration. vous avez des tests unitaires à l'intérieur de vos modules mais vous avez un autre module/projet qui exécute des tests d'intégration et vous voulez voir une couverture combinée
  • cela peut être très facilement résolu dans SonarQube 6.2+ car il a introduit la nouvelle propriété sonar.jacoco.reportPaths - qui prend plusieurs rapports fichiers et les fusionne.
  • Dans les versions inférieures de SonarQube, vous devez probablement fusionner les fichiers de rapports de test d'unité et d'intégration en un, en utilisant JacocoMerge. Dans notre projet, j'ai ajouté cette tâche:

    tâche jacocoMerge (type: JacocoMerge) {{ sous-projets sous-projet -> executionData FileTree (subproject.buildDir) .include ("/ jacoco/* exec.") } }

qui génère des fichiers de rapport qui fusionne tous les rapports sur tous les modules en projectRoot/build/jacoco/jacocoMerge.exec. Vous pouvez maintenant utiliser le chemin absolu pour ce fichier comme sonar.jacoco.reportPath pour tous les modules que vous souhaitez analyser.