Posts

Posted on

Reporting Unit Test and Integration Test Coverage In Sonar

If you are familiar with sonar, then the standard setup of the sonar plugin in your maven project will report Unit test coverage using Cobertura.

Sonar can also report Integration Test coverage using Jacoco

http://www.sonarsource.org/measure-coverage-by-integration-tests-with-sonar-updated/

However to report Integration test coverage on Multi-module maven projects, you may need you to tweak your build

Lets take this example

Projects:
Parent
Project A (jar)
Project B (jar)
Project C (Webapp utilising A and B)

Now if you do

mvn clean install sonar:sonar

on the parent project

What happens is the following

clean, install sonar:sonar will get run on project A
clean, install sonar:sonar will get run on project B
clean, install sonar:sonar will get run on project C

This setup may work if you want to report Unit Test coverage, but if you want to report Integration test coverage (where your integration tests get run against the final assembled war built in project C). The above is running sonar analysis too early for project A and B – as its project C that is will run integration test and produce the IT dump file for sonar to analyse.

You will need redo you your build to a multi-step one,

Multi-Step Build

Step 1 , You run mvn clean on the parent project, to delete everying in the target folder (including any Jacoco dump from previous runs )

Step 2 you run mvn install on the parent project, to run your unit tests and integration tests and produce the single Integration Test Jacoco dump file.

Step 3 from the parent, you run mvn sonar:sonar

Why run multi-step, well, it’s so that when you run sonar:sonar in Step 3, when its comes to analysis project A, B, C, sonar can refer to the single jacoco IT dump file which was produced in Step 2.

Details about Step 2

In Step 2, when you run you Integration tests, its good idea to separate Unit Test and Integration Test. maven-sure-fire plugin to run your Unit Test and maven-fail-safe plugn to run your IT tests.

Maven-fail-safe plugin extends the sure-fire-plugin.

The difference between the two plugins
The default convention for Surefire is that Tests follow the pattern **/Test*.java,**/*Test.java or **/*TestCase.java
Main goal is “test”

The default convention for Failsafe is that Tests follow pattern **/IT*.java, **/IT*.java or **/*ITCase.java
Main goal is “integration-test”

Right thats the difference between the two plugins sorted. We can use surefire to run our Unit Tests. and failsafe plugin (or launch external Java process e.g. Tomcat) to run our Integration Test

Now how to we get the failSafe plugin (or other Java process) to generate the IT Jacaco file in step 2 of our build?

If you are using fail-safe-plugin to run your Integration Test.
You’ll need to set the “argLine” config of the plugin to something like this

-javaagent:C:\tools\jacoco-agent.jar=destfile=C:\build\myparentprojectpath\target\itjacoco.exec,append=true,includes=com.mypackage.*

If for example you intend to run your integration tests as part of Tomcat, you can set the above argLine as your “CATALINA_OPTS” environment variable.

Note
One thing to bear in mind, the IT jacoco file is intially 0 bytes when but when the failsafe plugin or your java program ends, you should see the jacoco file being populated.

Super, now when your run your Integration Test in Step 2, you will have an produced an single itjacoco.exec file ready for Step 3 of your build

More about Step 3

Because we’ve already run our unit and integration test in phase 2, we want to avoid sonar having to re-run unit tests and integration test if possible, so we set this property in our maven build

-Dsonar.dynamicAnalysis=reuseReports

When sonar tries to work out the integration test coverage for project a, b, and c it needs to know where the global IT jacoco file is. So we need to pass another property to maven for this.

-Dsonar.jacoco.itReportPath=C:\build\myparentprojectpath\target\itjacoco.exec

Now sonar can report integertion test coverage in your mutli-module project.

Posted on

Nexus 7 Tablet, First impressions.

Got my Nexus 7 tablet. Was impossible to slide it out from the box sleeve, I had the cut the sleeve to get to the box.

What was inside box, however I was most pleased with, it a fantastic tablet, a bargain for the price. I watched Transformers 3 on it and it looked great on the 1280 by 800 screen, the tablet also gave me 15 pound google play store credit. Google play store had various computer books selling for a penny so I used my Google credit to buy some of these books. The 7 inch tablet is the perfect size for reading books on the Tube and by lucky coincidence the tablet slips snuggly into my inside jacket pocket.

Posted on

Getting Java HTTP Requests to appear in Fiddler

Fiddler is a handy tool to inspect http request/responses. When Fiddler starts-up by default it sets itself up to act as the proxy so any libraries that uses WinInet will have their http calls proxyied through Fiddler. For Java programs however you will need to instruct it to use Fiddler as a proxy if you want to see the calls in Fidder.

The properties you need to launch your Java application with, are:

-Dhttp.proxyHost=localhost -Dhttp.proxyPort=8888

Where 8888 is the default port that fiddler sets itself up, you can check this in Fiddler through Tools -> Fiddler Options

Refer to this StackOverflow post for more details

Few things to note :

  1. the above properties will work if you are using the standard Java libraries for making http requests. If you are using any other libraries for this (e.g. Commons HttpClient), then you’ll have to check if they have a different way of setting the proxy configurations.
  2. Secondly, requests for localhost for someone reason I can’t get them to go via the proxy (I guess the standard Java libraries has special rule for localhost). The work-round I had to employ is to use localhost. (note the dot after localhost this isn’t a typo )

If your using RestTemplate in conjunction with CommonsClientHttpRequestFactory (which uses Apache HttpClient underneath) then you need to set the HostConfiguration with proxy configuration. This blog I came across to describe the spring updates to do this

Posted on

Google Nexus 7 Tablet

Really looking forward to receiving my pre-order for Google Nexus 7 tablet, at 7 inch with 1280 * 800 resolution, quad core NVidia Tegra 3 Cpu with 12 Core GPU and at 340g, along with the updated 4.1 Jelly Bean OS, Early techrader preview sounds positive, I think google are onto a winner. Shame that it doesn’t come with a micro-sd slot and the shipping is 2-3 weeks 🙁

Posted on

Waffle

A very useful open source project I stumbled up on is waffle a Windows active directory authenication framework for C#/Java.

Posted on

Automated Swing Testing

For testing Swing UI, Jemmy is a really great tool. Some info about this can be found at

http://wiki.netbeans.org/Jemmy

and

http://jemmy.java.net/

and this is really useful powerpoint presentation I googled across:
Here

Another great tool is Fest-Swing , this uses Robot to generate Input Simulation.

I prefer Jemmy as it provides the option of using either Event Dispatching (events are programmatically created and dispatched onto the Event Queue) or Robot (using the Robot class to control the mouse and keyboard, generating native OS events like a real user using the UI) method for input simulation.

When you run the Tests on the Continuous build system, using Event Dispatch (the default mechanism for Jemmy) , it means you don’t need to have the process running inside a logged in windows desktop (it will still work even when it’s run as windows service account). The other advantage of Event Disptaching mechanism is that you when run the automated tests on your own machine you do not have to worry about your mouse and keyboard being taken control by the automated tests.