0

I have a multi-module maven project and want to generate code coverage reports for subsets of the project and track the results using sonar.

The project has modules M1, M2 and M3 and I want to generate coverage reports for package foo/** and for package bar/**. The packages may exist in multiple modules.

I'm using cobertura to generate code coverage files in my maven project.

My question is: what is best practice for generating multiple code coverage reports for a single project?

One option is to configure my maven build with a profiles to generate coverage data for specific packages, e.g. coverage-foo would configure the cobertura maven plugin with <include>foo/**</include>, and coverage-bar would configure the cobertura plugin with <include>bar/**</include>. Then I would configure sonar with two branches of the project: one for foo and one for bar, with no configuration on the sonar side.

But another option is to generate code coverage data for the entire projet, and configure each sonar project with appropriate inclusions. So the sonar 'foo' branch would have settings that only the foo/** files are included, and the sonar bar branch would have similar settings for the bar package.

Both seem equivalent to me (in terms of sonar output), and I favour the first option, but I'd like to know if this is the 'best practice' method of generating multiple code coverage 'views' of the same multi-module project. Or if one option has disadvantages that I have not considered.

(Note: there is a commercial 'views' plugin for sonar but I am restricted to free plugins for now)

John Q Citizen
  • 197
  • 3
  • 11
  • I talk about solutions, but not about your real requirement. What are those different coverage reports you need (UT / IT / Other) ? Why do you need coverage on packages spread among different modules ? Have you considered reorganizing your code base / modules ? In any case I would not use the branch feature of SQ as you will end with duplicate issues (there is no branch in SQ yet, you only duplicate projects giving them different keys) – Kraal Oct 22 '15 at 06:15
  • I'm only interested in unit test coverage for now. There are different teams working on different parts of the code base, and I'd like to generate coverage stats for each team. Unfortunately the code base is rather large and historical and it's not feasible to refactor the modules per team. – John Q Citizen Oct 22 '15 at 06:36
  • so why do your teams work on multiple modules ? and why do multiple teams work on the same module ? IMHO, you should map your teams to existing modules or refactor your code in order to make sure that a module is only maintained by a single team. Then you'll be able to have a single project and you'll have coverage by team out of the box. – Kraal Oct 22 '15 at 07:39
  • If a team works on multiple modules, think about moving those modules to standalone projects then integrating them in a View (see SonarQube commercial plugin "Portfolio") or write an external tool that calls SQ webservices to aggregates metrics (and thus coverage) on a module and cross project level and generates a pdf report. This is what we're doing (and it works like a charm) – Kraal Oct 22 '15 at 07:39
  • All good points, but I don't have the authority for such large-scale refactoring of a product with over 1.5M LOC. Can only work with what I got. – John Q Citizen Oct 23 '15 at 00:19

1 Answers1

0

Given our message exchange and the information you provided, I would rather go for a mix of the 2 options in your context, i.e.:

  • generate code coverage data only for foo (or bar)
  • have sonarqube analyse your code in a way where a branch is created for foo (or bar) where only foo code (or bar code) is included

Indeed this would allow you to have the information you need about coverage, but will also allow you to only have issues related to foo / bar code.

Nevertheless, you'll have two issues then :

  1. code that is not part of foo nor bar won't be analysed unless you create another branch where you would exclude foo AND bar code
  2. you won't be able to have a global picture of your code quality, to do it you would have to use the portfolio plugin (but as you wrote, you can only use opensource plugins

Note that the 2. point is not that problematic as you can rebuild the information you need using SonarQube's web service (this would allow you to build an external report that would aggregate data you want to be aggregated)

Michel

Kraal
  • 2,779
  • 1
  • 19
  • 36