©2017 by Michael Duquette. Proudly created with

  • Michael Duquette

Before we get started there a couple of assumptions I am making:

  • You have a current Gradle project and you want add Code Coverage testing

  • You are using Junit 5 (Jupiter) for testing

Ok first and for most backup your existing project. If following my steps causes you to screw something up that’s on you. Especially since my first step in this adventure clearly states backup your existing project! Backup complete? Ok lets move on.

Go to github and fork the gradle-clover-plugin repository:

Now open your projects build.gradle and the plugins build.gradle. Wildly different right?! Now merge the two. My project didn’t have any funky dependencies or imports so I literally copied the plugins build.gradle and overwrote mine. There are about nine different plugins used for the Gradle Clover Plugin. Read the projects build.gradle and understand it. This will help assure there are no failures. Remember I did tell you to backup your project before starting.

Once you sort out your build.gradle look in the Gradle Clover Plugin repository and open up the gradle folder. Copy the six *.gradle files to your projects gradle folder. These should be:

  • additional-artifacts.gradle

  • documentation.gradle

  • functional-testing.gradle

  • integration-test.gradle

  • publishing.gradle

  • release.gradle

Now back to the Gradle Clover Plugin repository copy the src folder to your project and overwrite your src folder. You will now have three folders in your src folder:

  • funcTest

  • main

  • test

funcTest contains all the functional testing scripts while main and test contain an additional groovy folder with scripts specific for Groovy. Now if you just overwrote your src directory your code should still be in the java folders under main and test. If not go to your backup and copy them over. This is why we do backups.

Now once again back to the Gradle Clover Plugin repository. Copy the file over from the root of the repository to the root of your repository. Open it up with your favorite editor (I like to use Notepad++ ) and check it out. What are we looking at here? Well this sets your current Gradle version build level and the testing versions as well. You can modify this to test against specific versions of Gradle.

TIP: Keep gradleTestingVersion list short and only test against the version of Gradle you need to. This will reduce your build time.

Now open a bash terminal and fire off a gradle build. Oh your code failed with a compilation error because of javaDocs and GroovyDocs? Clean up your code! No seriously, I was shocked the first time I ran it that I had 12 errors all related to java docs. Now these were errors that JaCoCo, Spotbugs, Checkstyle and PMD did not report. One of which was: @param firstName was missing a description. It was helpful to have the line numbers right there on the screen and I was quickly able to resolve my issues.

Now that you’ve cleaned up your code do another gradle build. Once your build succeeds navigate to the $repository_name/build/reports/tests folder you will see two sub-folders test and functionalTest. Drill into these folder and open the index.html file to see your test results.

Now that you are all setup head over to OpenClover and to the gradle-clover-plugin repository and learn how to tweak the setup for your use.

#CS@Worcester #CS-443

  • Michael Duquette

This is the first in a series of two posts. First we’ll cover the why and the second post will cover the how. Getting OpenClover setup on an existing project took some massaging that will be rather lengthy to explain. OpenClover is based on Atlassian’s Clover product. Atlassian released the source code for Clover and offers OpenClover as a free and open source product.

Why OpenClover instead of JaCoCo? Well the code coverage is more complete then JaCoCo and the other alternatives. OpenClover provides plugins for CI servers like Jenkins, Bamboo and Hudson and integrates with ANT, Maven, and Grails. OpenClover also integrates with IntelliJ IDEA and Eclipse. OpenClover covers Java, Groovy and AspectJ while tracking global coverage and per-test coverage. Reports are generated on three kinds of metrics: method coverage, statement coverage, and branch coverage.

For a complete list of features see the features page at

I find the ability to integrate OpenClover with my IDE (IntelliJ or Eclipse – I use both) appealing. Being able to run tests from the IDE would be very helpful. I’m not sure if any of the other products available for Code Coverage testing can integrate with an IDE.

Follow this link for a general comparison on Code Coverage products. I found it helpful when researching alternatives to JaCoCo. Unlike most reviews/comparisons I have found on line this one includes links to each of the products discussed.

Stay tuned for my second post on Implementing OpenClover with an existing Gradle project.

#CS@Worcester #CS-443

  • Michael Duquette

Updated: Dec 1, 2019

Does your unit test have a stunt double? You know someone to jump in there and take the hit during testing instead of using real dependencies? Well, it could if you used Mockito.

I found a great tutorial on setting up Mockito for various environments and situations here:

But what is Mockito? Don’t confuse it with that lovely mint based rum concoction. It’s a JAVA based mocking framework. It’s used to mock interfaces so that dummy functionality can be used in unit testing.

But what is mocking? In OOP mock objects are simulated objects that mimic the behavior of real objects (stunt doubles!). In Test Driven Development mock objects meet interface requirements of real objects allowing developers to write and unit-test functionality. This allows the developers to focus on the behavior of the system while testing without worrying about dependencies.

This Martin Fowler article does a great job explaining Mocks:

So grab a Mojito and enjoy some reading!

#CS@Worcester #CS-443