Thursday 30 January 2014

Bugs types

Incompatible classes

when you try to deserialize files generated with old code...
Les trouvailles dInternet pour bien commencer la semaine #161 130114 18



























Wrong URL setting

when you put a wrong rest url in your property file and you receive no messages...
Les trouvailles dInternet pour bien commencer la semaine #160 060114 6



Too verbose xml messages

when SLAs are not met because your XML messages are too big wasting time in serialization and deserialization...
Les trouvailles dInternet pour bien commencer la semaine #162 200114 15





Production with no tests

when you go in production and you expect that everything will go fine even if you didn't test all the possible paths...

Les trouvailles dInternet pour bien commencer la semaine #162 200114 23






 

 

   

Too many requests, site is down

when you go in production without never running stress tests before...
 Les trouvailles dInternet pour bien commencer la semaine #158 161213 11



Threads bottleneck

when you spawn threads and you think it will be faster, but you forgot that synchronized method...
 Les trouvailles dInternet pour bien commencer la semaine #158 161213 20




Threads interference

when you forgot to coordinate your threads...
 Les trouvailles dInternet pour bien commencer la semaine #154 181113 25





Bug in an external library

when that external library that you choose is not behaving as expected...
 Les trouvailles dInternet pour bien commencer la semaine #153 121113 22




Wrong usage of a library

when you tried to use a library without reading the documentation...
 http://i.imgur.com/nJdP4.gif








Access private fields in unit tests

First of all, let me say out louder, you need to design your code to be testable, so you test your private fields through your public methods.

But, ("buts" are the reasons why humans are still programming instead of the computer itself, so be happy here) sometimes you want to and should alter some private fields in order to test all the possible boundaries.
Often private fields can be modified through public getter and setters or using the class constructor and in those cases the tests are easy to create and everybody is happy.
But when you use external frameworks like Spring, it may be possible that you do not have control over injected private fields.
I already explain how to mock spring components in your tests without the need of maintaining and creating ad-hoc test spring configuraitons in a previous post, here I will show you how to modify a private variable for your tests.

Let speak code:


import javax.annotation.PostConstruct;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.stereotype.Service;
import com.google.common.collect.ImmutableSet;
@Service
public class SomeService {

        @Value("${whitelist.api.users:A,B,C}")
        private String apiUsers;

        private ImmutableSet<String> acceptableAPIBUsers;

        @PostConstruct
        public void init() {
                acceptableAPIBUsers = ImmutableSet.copyOf(apiUsers.replaceAll(" ", "").split(","));
        }

        public boolean isAnAcceptableUser(String user) {
                return user == null ? false : acceptableAPIBUsers.contains(user.toUpperCase());
        }
}


We do not have control over  the apiUsers String, so we have couple of straightforward options, one is to create a Spring configuration for your test, modify the Spring context and mock the property, two is to create a setter to change the value of the property from your test.
I discourage from creating public assessors only for you tests, it is confusing for other people looking at your code and creating and maintaing Spring configurations for your tests can be a pain.

I know what you are thinking, "if I cannot do either of the above I'm going to get fired, my girlfriend will leave me and my life is finished", but don't you worry, I'm here to show you another option ;)



You can create a groovy class with a static method to assess your private field in your test :


import groovy.transform.CompileStatic
@CompileStatic
class SomeServiceAccessor {

        public static void setApiUsers(SomeService someService,String apiUsers){
                someService.@apiUsers = apiUsers
        }
}

And use it in your unit test:

import static org.hamcrest.CoreMatchers.is;
import static org.junit.Assert.assertThat;
import org.junit.Before;
import org.junit.Test;
public class SomeServiceTest {

        private SomeService service;

        @Before
        public void setUp() {
                service = new SomeSercvice();
                SomeSercviceAccessor.setApiUsers(service, "pippo,pluto,bungabunga");
                service.init();
        }

        @Test
        public void testIsNotApiUser() {
                assertThat(service.isAnRTBUser(""), is(false));
                assertThat(service.isAnRTBUser(null), is(false));
                assertThat(service.isAnRTBUser("random"), is(false));
        }

        @Test
        public void testIsRTBUser() {
                assertThat(service.isAnRTBUser("pippo"), is(true));
                assertThat(service.isAnRTBUser("PIPPO"), is(true));
                assertThat(service.isAnRTBUser("pluto"), is(true));
                assertThat(service.isAnRTBUser("bungabunga"), is(true));
        }
}

Of course you can do the same in java changing the visibility of the field with reflection, but I think the groovy solution can be a cleaner and easier way.

Now, I ll finish this post with the following recommendation:

Do not use this solution unless you really really really need to modify private variables to unit test your class! 

Wednesday 15 January 2014

Testing Spring components with Mockito

Be able to unit test your spring components without the need of loading the full spring-context with its ad-hoc test configurations it is ,in my opinion, a great advantage because it's clean, easy to maintain, faster to write, smooth to alter.

A way to achieve this goal is to use Mockito and tell him to replace the @Autowired components in the class you want to test, with Mocks ( or Spies ).

Here an example.
We have a service called SalaryService that guess what, is calculating a hypothetical net salary based on the employee id passed. Easy concept.

The service required two collaborators, one, the EmployeeDAO, to retrieve the gross salary and a second one, the TaxCalculator, to apply some taxes based on the gross salary.

package com.marco.springmockito;
import java.math.BigDecimal;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;
@Component
public class SalaryService {

    private static final BigDecimal minimumSalary = new BigDecimal(20000);

    @Autowired
    private EmployeeDAO employeeDAO;

    @Autowired
    private TaxCalculator taxCalculator;

    public BigDecimal getNetSalary(long employeeId) {
        BigDecimal netSalary = null;
        BigDecimal grossSalary = employeeDAO.getAnnualSalary(employeeId);
        BigDecimal taxes = taxCalculator.calculateTaxes(grossSalary);
        if (taxedSalaryIsGreaterThanMinimumSalary(grossSalary)) {
            netSalary = grossSalary.subtract(taxes);
        } else {
            netSalary = grossSalary;
        }

        return netSalary;
    }

    private boolean taxedSalaryIsGreaterThanMinimumSalary(BigDecimal taxedSalary) {
        return taxedSalary.compareTo(minimumSalary) == 1;
    }
}


EmployeeDAO is a classical service that is in charge of retrieving information from a persistence storage and it will look like this more or less.

package com.marco.springmockito;
import java.math.BigDecimal;
import org.springframework.stereotype.Component;
@Component
public class EmployeeDAO {

    public BigDecimal getAnnualSalary(long employeeId) {
        // conncetTODB
        // run select for employeeId;
        return new BigDecimal(70000);
    }
}


TaxCalculator will need a TaxDao to retrieve taxes information and it will then operate some sort of boring and long calculation in order to return the taxes.

package com.marco.springmockito;
import java.math.BigDecimal;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;
@Component
public class TaxCalculator {

    @Autowired
    private TaxDao taxDao;

    public BigDecimal calculateTaxes(BigDecimal salary) {
        BigDecimal result = salary.multiply(taxDao.getTaxPercentageForYear(2014));
        // some other weird calculation ....
        return result;
    }
}


Now, we want to unit test the SalaryService class. We should not to be bothered by DAOs and databases setup of any sort. In this UNIT test, we don't care here what the TaxCalculator is doing.

What we want is to test that our SalaryService is behaving as expected and that it is able to correctly use the work of its collaborators.

Here is how we do it with Mockito. We mark the class we want to test with @InjectMocks and we mark with @Mock all of its collaborators ( or @Spy if you need a real implementation ).

Lastly we need to tell our Unit framework, to operate the required Mockito injections before starting the test and we do this with MockitoAnnotations.initMocks(this);.

In the test we need to mock the expected operations so that we can concentrate on the actual logic we want to test inside the SalaryService .

package com.marco.springmockito;
import static org.hamcrest.core.Is.is;
import static org.junit.Assert.assertThat;
import static org.mockito.Mockito.when;
import java.math.BigDecimal;
import org.junit.Before;
import org.junit.Test;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.MockitoAnnotations;
public class SalaryServiceTest {

    private static final long UserId = 123l;

    @InjectMocks
    private SalaryService salaryService;

    @Mock
    private EmployeeDAO employeeDAO;

    @Mock
    private TaxCalculator taxCalculator;

    @Before
    public void init() {
        MockitoAnnotations.initMocks(this);
    }

    @Test
    public void testMinimumSalary() {
        BigDecimal annualSalary = new BigDecimal(10000);
        when(employeeDAO.getAnnualSalary(UserId)).thenReturn(annualSalary);
        when(taxCalculator.calculateTaxes(annualSalary)).thenReturn(new BigDecimal(1000));
        BigDecimal actual = salaryService.getNetSalary(UserId);
        assertThat(actual.compareTo(new BigDecimal(10000)), is(0));
    }

    @Test
    public void testMaximumSalary() {
        BigDecimal annualSalary = new BigDecimal(80000);
        when(employeeDAO.getAnnualSalary(UserId)).thenReturn(annualSalary);
        when(taxCalculator.calculateTaxes(annualSalary)).thenReturn(new BigDecimal(8000));
        BigDecimal actual = salaryService.getNetSalary(UserId);
        assertThat(actual.compareTo(new BigDecimal(72000)), is(0));
    }
}

It is simple and efficient and hopefully it will be useful for someone else out there.