This post is a kind of follow up post to Gradle rocking Scala Specs2 tests. After setting up the build supporting Specs2 tests we could take it a step further to provide information about the code coverage of the tests.
SCCT is a code coverage tool for Scala. One benefit of SCCT is that the output format is compliant, to the widely known Cobertura so it could easily integrated into Jenkins for example.
To prepare your Gradle build there is an SCCT plugin available at GitHub. Following the instructions on the project page should result in a similar project file:
buildscript { repositories { mavenCentral() } dependencies { classpath 'com.github.maiflai:gradle-scct:0.3' } } apply plugin: 'scala' apply plugin: 'scct' apply plugin: 'idea' repositories { mavenCentral() } dependencies { scct 'com.github.scct:scct_2.10:0.2.1' compile 'org.scala-lang:scala-library:2.10.+', 'net.sourceforge.htmlcleaner:htmlcleaner:2.2', 'org.apache.httpcomponents:httpclient:4.3.1', 'com.typesafe:scalalogging-slf4j_2.10:1.0.1', 'org.slf4j:slf4j-simple:1.7.5', 'com.github.scopt:scopt_2.10:3.1.0' testCompile 'junit:junit:4.+', 'org.scalatest:scalatest_2.10:2.+', 'org.specs2:specs2_2.10:2.2.3' }
To resolve the „reaktor:scct_2.10:0.2-SNAPSHOT“ dependency the GitHub maven repository is explicitly added to the „repositories“ entry. SCCT could be easily obtained from maven central. After enhancing the build file with the SCCT plugin there are a few new tasks including „testScct“.
To use the instrumented classes during the Specs2 test execution the custom task has to be adjusted to the new classes location. This is achieved by replacing the sources main class path (sourceSets.main.runtimeClasspath) with the target directory of the SCCT instrumentation task (e.g. build/classes/scct):
/** * Run Spec2 tests */ task specs(type: JavaExec, dependsOn: testClasses) { main = 'org.specs2.files' args = ['console', 'junitxml'] //classpath sourceSets.main.runtimeClasspath classpath 'build/classes/scct' classpath sourceSets.test.runtimeClasspath classpath configurations.scct classpath configurations.testRuntime classpath configurations.runtime }
Finally let the testScct task depend on the Specs2 task to have automatically executed the tests when running the testScct task:
/* * add dependency for code coverage task as well */ testScct.dependsOn specs
After running the testScct task there is a cobertura.xml file containing your code coverage data. Having your Gradle build up and running including automated tests and code coverage analysis fits very well and enables you to quickly set up an automated build on an integration server like Jenkins. The Cobertura format is widely understood and supported. You might take a look at https://mindcrime-ilab.ci.cloudbees.com/job/CVDL Develop/ for a demonstration.
Caveats
All report files are created at the project root. I have to investigate how to change it to a defined report dir.
Update 2013/11/19
Adopt the build.gradle to the new SCCT 0.2.1 release available on maven central. SCCT is now available from maven central and has changed the organisation id to com.github.scct.
Eine Antwort auf „Deliver code coverage indices for Scala using Gradle and SCCT“
[…] Michael Engelhardt showed us how he delivered code coverage indices for Scala using Gradle and SCCT […]