Stay the Same: Spring Boot - Unit Test, Coverage Test, Sonarqube

What is more interesting than writing unit test and be sure that there is no bug in our program? In this post we will create a unit test for our Spring Boot application. After that we will do a coverage test, and use Sonarqube to see what we missed.

First, modify our pom.xml by adding spring boot starter test dependency.

Create a package for testing and a test case class.

Next, modify the test case class as shown below. We annotate the class with @RunWith(MockitoJUnitRunner.class) to indicate that it is a JUnit class. JUnit will run our test case class, CustomerTestCase, in MockitoJUnitRunner runner class. Here we use MockitoJUnitRunner because we want to mock some objects that are managed by Spring. By mocking a class means creating a fake object of that class. An example is mocking a DAO class to unit test a service or controller. A DAO class is managed by Spring, created and destroyed by Spring. When unit testing a service, it is not possible to ask Spring to inject that DAO. Instead, we can create a mock object of that class.

Since we want to test our CustomerController, we create a CustomerController object and annotate it with @InjectMocks. This means we want to create an object of this type. We also create ICustomerDao and Customer object and annotate them with @Mock. This means fake objects of ICustomerDao and Customer are created and will be injected into CustomerController. Note that CustomerController has variable type ICustomerDao and Customer.

We also have two methods and annotate them with @Before/@After. This means those methods will be run before/after all test methods have been run.

Lastly, we have two methods annotated with @Test. These are the real test case methods. The method must be a public void method. The testInsert() method calls CustomerController.addCustomer() method. The testUpdate() calls the same method, but before calling the method, it asks Mockito to replace customer.getId() with value 1. This is very useful if we want to simulate a customer that already has an id.

However when we run it, it gives an error on this line of CustomerController.addCustomer() method: FacesContext.getCurrentInstance().addMessage(null, facesMessage);. This happens because FacesContext.getCurrentInstance() returns null on unit test. What we can do is surround that code with an if condition to check for null value as shown below. This is, I think, the drawback of Mockito. Somehow we have to modify our code to make Mockito satisfied.

Running it will produce the following result on Eclipse.

Next we will use Eclipse code coverage tool. Eclipse Photon for Java EE Programmer is equipped with code coverage plugin. All we need to do is right click our test case class and run JUnit test coverage as shown below.

Once the test finished, our test case class will be highlighted green as shown below. It means the methods have been run completely.

And our controller is highlighted like this: Red means it never gets executed. Yellow means it is an if-else condition and gets executed. Green means it is executed.

The coverage percentage is shown below. It means in total only 11.6% of our code unit tested.

Next tool we will try is Sonarqube. We can download it from its website. At the moment of writing this post, the last version available is 7.4. They provide a setup information on their website to get sonarqube running as shown below.

Next we will see how to analyze our project. Once we logged in, click on the following Documentation sub menu as shown below.

Click left sub menu Analyzing Source Code.

SonarQube provides many code scanner depending on our project. Since we use maven as our build tool, we will choose Scanner for Maven link.

Once we click the link, a new page is displayed. We need to follow Initial Setup instruction on how to setup settings.xml file on our maven home folder. Here we add two sections, <pluginGroup> and <profile>.