Together: PIT, SonarQube and Gradle

This will be another “putting it all together” post, and you can jump to Putting Them Together below, but as a brief recap…


One of the testing tools I like to use is Pitest (PIT). It’s a mutation testing framework for Java.  Mutation testing introduced typical bugs into your code as mutations and then runs your tests to see if those errors are caught.  It’s testing the robustness of your tests.


SonarQube is a code quality testing tool. It offers a great why to perform a bunch of static analysis on your code, offering insights into test coverage, complexity, best practices etc. It runs as a free standing server and is often used by groups and organizations.  But if you’re comfortable with docker and docker hub it can be installed and running on a laptop in under two minutes, so there’s no reason not to use it as an individual too.


Gradle is my build automation tool of choice…

Putting Them Together

Scattered about there’s information how to get these tools working together but I’ll try to cover it end to end here to make life simpler.

Gradle Driving Mutation Tests

This is simple to do, and the plugin documentation is good. For our purposes though there’s a bit of key configuration in your build.gradle:

plugins {
  id 'info.solidsoft.pitest' version '1.1.4'

pitest {
   threads = 4
   timestampedReports = false
   outputFormats = ['XML', 'HTML']

The key bit here is the timestampedReports = false.  By default PIT puts reports in a new directory every run.  We want the reports to consistently go to the same dirctory for automation’s sake. This flag does the trick. Once you have the above in place you can test it with:

    $ ./gradlew pitest

And you should find your report in ./build/reports/pitest/index.html.

SonarQube PIT Support

Next we need SonarQube to support PIT, this is done with a plugin and some settings. I’m assuming different versions of SonarQube will have variations on this so I’m not going to screen shoot every step but here’s how I did it with 6.1:

  1. Logged in as admin
  2. Selected “Administration” from the top bar menu
  3. Selected “System->Update Center” from the administration menu
  4. Selected “Available”
  5. Searched for “pitest”
  6. Selected “Install”

Okay, after the plugin is installed you’ll need to configure it:

  1. Back to the “Administration” page
  2. On the list there should now be “Pitest” select it
  3. Under “PIT activation mode” enter “reuseReport”
  4. Under “Output Directory for the PIT reports” enter “build/reports/pitest”

That should do it. The plugin is in place and knows how to play nice with gradle.

Gradle to SonarQube

Now gradle can generate the mutation tests, and SonarQube can accept them.  This is how you connect them up. First update your build.gradle with the SonarQube plugin:

plugins {
   id 'org.sonarqube' version '2.2.1'

And then you need to a tell the plugin where to find the SonarQube so add the appropriate URL to your

With those two additions you should now be able to:

    $ ./gradlew pitest sonarqube

And it should all just work.

What Did We Get?

Now on SonarQube, for the project in question, there should be a new Mutation Analysis section on the Measures page with the results of PIT.


Signs The Jobs Not Right

Recently I read the following account of a truly horrible interview process. Several of the comments on the article were along the lines of “when the interview is like that, what do you think the job will be like?”  This got me thinking again about my own recent job search and one recurring issue, the use of tools like HackerRank.   Here’s the thing about me and HackerRank, I don’t do particularly well with it.  Between the generally short time boxing, and the very limited tool, I struggle.  You might respond that that is the point.  If someone can’t quickly solve a problem, with whatever tools they are handed, that says something about their abilities.  I acknowledge that.  My issue with it is, it may not be the exact abilities that you should be looking for, particularly in a senior technologist.  Yes you want a quick mind. Yes you want an adaptable person. But if you’re looking for someone senior you probably want high quality output and good communication skills and for those of us that aren’t Richard Feynman, that may mean some analysis and process. I fully expect my jobs to require good work in a reasonable time on tough problems, and I expect to exceed expectations, but I’m going to do it by thinking a bit, designing a bit, and using good habits like TDD, none of which I can do particularly well in 20 minutes in HackerRack.

I was more then happy to to share work samples, or solve a code challenge over night turning in my solution, but when they immediately threw HackerRank at me, I knew that I wasn’t going to like the culture or do well in the interview process.