1

I am migrating a Maven Project to Gradle and I have an issue with my code coverage plugin : Clover. I have an unexplained behavior about coverage computation. Let's take a simple example :

// ProjectA

class A
{
    void method1()
    {
        // Some stuff
        // This method is covered by a unit test in ProjectA
    }

    void method2()
    {
        // Some stuff
        // This method is not covered by any unit test in ProjectA
    }
}

// ProjectB

class B
{
    void method3()
    {
        new A().method2();
        // Some stuff
        // This method is covered by a unit test in ProjectB
    }
}

I have 2 different project : ProjectA and ProjectB. ProjectB depends on ProjectA.

ProjectA contains a class named A. method1 from A is covered by a unit test contained in ProjectA. method2 is not covered by any test contained in ProjectA.

ProjectB contains a class named B. method3 from B is covered by a unit test contained in ProjectB. method3 calls method2 from class A in ProjectA.

The fact :

With Maven and Clover (official plugin), method2 is considered covered as it's call from a method (method3) covered by a unit test, even if the test is in a different project. With Gradle and Clover (unofficial plugin), method2 is considered uncovered as there is no dedicated test in ProjectA.

The configuration is kind of basic, no major difference between Maven and Gradle Clover plugin.

My questions :

What is the normal / default behavior of Clover ? Can this behavior be set through configuration ? Or is this some kind of bug in the Gradle Clover plugin ?

ToYonos
  • 16,469
  • 2
  • 54
  • 70
  • Are you tied to clover? In my opinion [JaCoCo](https://docs.gradle.org/current/userguide/jacoco_plugin.html) is superior to clover since it instruments on-the-fly (using a java agent) without manipulating class files. It's the de-facto standard for gradle builds – lance-java Feb 10 '17 at 10:34
  • But on-the-fly instrumentation does not work with Powermock https://github.com/powermock/powermock/wiki/Code-coverage-with-JaCoCo – ToYonos Feb 10 '17 at 12:23
  • Hehe... so switch to [mockito](http://site.mockito.org) too then... (half kidding, half not!) – lance-java Feb 10 '17 at 14:10
  • Also using Mockito but PowerMockito too ;) – ToYonos Feb 10 '17 at 14:29

1 Answers1

2

Now that we've got the fun out of the way and ruled out JaCoCo, I think you'll need to provide clover with additional source dirs

Eg:

apply plugin: 'com.bmuschko.clover'

evaluationDependsOn ':someOtherProject'    
clover {
    additionalSourceDirs = project(':someOtherProject').sourceSets.main.allSource.srcDirs
}
lance-java
  • 25,497
  • 4
  • 59
  • 101
  • Interesting idea. I will test it and get back to you. – ToYonos Feb 10 '17 at 16:01
  • I had an issue with your answer, a `Could not find property 'sourceSets'` issue, related to this question i guess http://stackoverflow.com/questions/15347364/gradle-multiproject-gives-could-not-find-property-sourcesets-on-project-erro Anyway, I hardcoded the path of `ProjectA` (for the sake of the test, temporarily) and it worked ! My clover.xml file at the root of the project was filled with the proper coverage. I have to figure out this sourceSets issue but my initial issue is fixed. Thank you. – ToYonos Feb 13 '17 at 10:14
  • Updated my answer to include `evaluationDependsOn ':someOtherProject'` – lance-java Feb 13 '17 at 10:16
  • Actually I did not use `evaluationDependsOn`, my project architecture was a little too complex for that but moving the instruction to a better place did the job. Anyway, it does not change the fact that the initial answer was perfectly accurate. – ToYonos Feb 13 '17 at 12:00