Hi everyone,

Currently I'm trying to generate overall code coverage report and have some
troubles.
To generate code coverage report I run maven from the root: *mvn clean
install -Pjacoco-report*
It creates for me JaCoCO reports, however under each module separately. To
get a whole picture about code coverage I  use Sonar and Maven Sonar
plugin(*mvn
sonar:sonar*). And unit tests's covers code coverage is about 32%.

However with integration tests the situation is a bit trickier. If I run *mvn
clean install -Pjacoco-report* from the root it doesn't create a report for
integration tests under *launchpad* directory. I have also tried to follow
the instruction from SLING-1803(penultimate
<https://issues.apache.org/jira/browse/SLING-1803?focusedCommentId=13627948&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13627948>
comment) and applied a patch from this ticket, but it didn't help me. So
probably I just do something wrong and there is a nice and easy solution or
I just should investigate this problem deeper?

Thanks in advance,
Petr

2015-03-04 11:46 GMT+03:00 Bertrand Delacretaz <[email protected]>:

> Hi Petr,
>
> On Wed, Mar 4, 2015 at 9:38 AM, Petr Shypila <[email protected]> wrote:
> > ...My name is Petr and I want to work on SLING-1437
> > <https://issues.apache.org/jira/browse/SLING-1437> issue under the
> Google
> > Summer of Code 2015 program....
>
> Cool! Expanding our test coverage is always welcome.
>
> > ...Are there some components on which I should
> > concentrate and investigate more than on other?...
>
> As a starting point I would suggest creating a coverage report that
> combines the unit and integration tests found in the individual
> modules and the integration tests that the launchpad/testing module
> runs. IOW, be able to find out the combined coverage for a given
> module, including what launchpad/testing tests on top of the tests
> found in the module itself.
>
> There's been a few attempts at that in SLING-1803 but it's not
> integrated in our main codebase at the moment.
>
> Once that's done we can look at which modules need more attention. In
> general, code that's in the bundles folder is more important than the
> rest.
>
> -Bertrand
>

Reply via email to