Has been a while, I was thinking to blog this out but “lazy” bugs keep biting me 🙁 so I didn’t manage to do it. Until yesterday, I was looking for some related info but I hardly recall what I did previously. Phew… so decided to jot down here.
Typically software application should at least perform 2 types of automate tests which are unit test and integration test. For me… the distinction between these two are pretty straight forward:
| Unit Test |
Integration Test |
| Test on smallest unit of application such as method / function |
Test on combination of few units in application to prove they run nicely with external resource (if there is any) |
| Cheap to run, fast to run (normally less than a minute) |
Slower compared with unit test (normally few minutes or more) |
| NOT depends on external resources such as database, third party services, disk access |
Normally involve database, disk access, other services |
| Mock the input of unit test if necessary |
Use the real service / resource |
| Maven Plugin Usage |
| Class name normally suffix with “Test”, for eg: TaxCalculatorTest (Maven Surefire plugin automatically include these wildcard patterns) |
Class name normally suffix with “IT”, for eg: TaxCalculationServiceIT (Maven Failsafe plugin automatically include these wildcard patterns) |
| Using Maven Surefire Plugin |
Using Maven Failsafe Plugin |
| Run during “test” phase in default Maven lifecycle |
Run during “integration-test” phase in default Maven lifecycle |
Minimal sample Maven configuration:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>${maven.surefire.version}</version>
<executions>
<execution>
<id>default-test</id>
<goals>
<goal>test</goal>
</goals>
</execution>
</executions>
</plugin>
|
Minimal sample Maven configuration:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<version>${maven.failsafe.version}</version>
<executions>
<execution>
<id>default-integration-test</id>
<goals>
<goal>integration-test</goal>
</goals>
</execution>
</executions>
</plugin>
|
Command to execute:
mvn test
|
Command to execute:
mvn integration-test
|
| Report generated in <PROJECT>/target/surefire-reports |
Report generated in <PROJECT>/target/failsafe-reports |
By viewing the status report generated by surefire & failsafe plugin doesn’t create much insight, but we can make use of Jacoco plugin to create code coverage report as below.
Here are minimal sample Maven configuration for Jacoco:
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>${jacoco.version}</version>
<executions>
<execution>
<id>default-prepare-agent</id>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<execution>
<id>default-prepare-agent-integration</id>
<goals>
<goal>prepare-agent-integration</goal>
</goals>
</execution>
<execution>
<id>default-report</id>
<goals>
<goal>report</goal>
</goals>
</execution>
<execution>
<id>default-report-integration</id>
<goals>
<goal>report-integration</goal>
</goals>
</execution>
</executions>
</plugin>
Jacoco coverage reports generated at <PROJECT>/target/site/* when we run mvn verify (bind to maven verify phase). To view the coverage reports, simply open <PROJECT>/target/site/jacoco/index.html with browser.
Yay ! we have now cover first part of test (automate unit + integration test), and if you notice, we done all steps manually (run maven command, open report from target folder) just to get the report display.
Moreover, we just able to view the coverage report locally, how if we want to share with other team members or to make it public accessible.
And…….. How can we automate the whole process ?
Da.. Dang !! We have Jenkins (Continuous Integration) + SonarQube (Continuous Code Quality Inspection) to help us 🙂
Setting up Jenkins is pretty straight forward, just follow steps from Jenkins Guided Tour or Installing Jenkins. We should able to see something as below if Jenkins setup successfully and launch in browser.
Let’s continue with SonarQube setup by following “Get Started in Two Minutes” guide from it’s official site. And if nothing goes wrong, we should able to bring up SonarQube console via browser as below:
Until this stage, you might feel a little tired or sleepy, it’s okie to refresh yourself with a cup of coffee 🙂
To allow Jenkins to work with SonarQube, we might need a little setup as below.
- Install SonarQube Scanner for Jenkins.
- Generate authentication token from SonarQube and store it somewhere as steps below for subsequent Jenkins configuration use.
- Goto Manage Jenkins –> Configure System, There should have SonarQube configuration module available.
Just configure it by click on Add SonarQube, and fill in necessary information (sample below), then Save it.
- After setting up Jenkins – SonarQube, the next step is to add a Post Build Steps (SonarQube Scanner) for your Jenkins job as below:
Note: Sample analysis parameter added above are very minimal, refer Analysis Parameter or Code Coverage by Unit Tests for Java Project for more parameter available.
- Rerun your Jenkins job after configuration, and you will see the analysis report generated in SonarQube as below.
- Yay !!!! We can now have beautiful test coverage report generate upon each code commit (of course, we need to configure Jenkins job to trigger build on each code commit to make these “magic” happen).
After some hard time, manage to figure out why…….. phew….
Credit to BalusC @ stackoverflow
