we are building an Android app which is tested by using Appium. Now I would like to see the test coverage of our Appium tests. I think this is possible, because Jacoco supports offline instrumentation (http://www.eclemma.org/jacoco/trunk/doc/offline.html).
And even the documentation of the jacoco gradle plugin says:
While all tasks of type Test are automatically enhanced to provide coverage information when the java plugin has been applied, any task that implements JavaForkOptions can be enhanced by the JaCoCo plugin. That is, any task that forks Java processes can be used to generate coverage information.
see https://docs.gradle.org/current/userguide/jacoco_plugin.html
But how do I have to write the build.gradle so our acceptance debug flavor is instrumented and the exec file is written to the Smartphone when the Appium tests are executed or even manual test cases are executed? Because then I can extract the exec file and send it so SonarQube for further analysis.
Thanks Ben
Finally I managed it to get it working and I want to share the solution with you:
enable instrumentation for your buildType and configure SonarQube accordingly e.g.
add the following to your AndroidManifest.xml
CoverageDataDumper should look like that:
Then run your Appium test cases with the acceptance flavor app (with instrumented classes). Before you call "Reset App" or "Close Application" make sure to call the following methods (just a draft, but I think you get the idea):
outputPath could be for example: /sdcard/Android/data/org.example.acceptance/files/coverage.ec
Now the Jacoco data is written to the Smartphone. Next we need to download that file. You can use
Now you need to copy the file "jacoco-it.exec" (which should always be appended when you pull the file) into build/jacoco/jacoco-it.exec see gradle.build above and run
In SonarQube add the Integration Test Coverage Widget and you should see now some values...
Unfortunately code coverage won't work if you are using retrolambda (as we do). Retrolambda will generate anonymous classes which are not part of the source files - so SonarQube cannot match them correctly and displays a much lower code coverage than it actually is. If someone finds a solution for that, I would be very happy :-)