Thursday, 19 June 2014

How to test circular dependencies in Spring

This will raise an exception if your dependencies have circular dependency problem

import org.junit.Test;
public class IngesterCircularReferencesTest {

        public void circularReferencesTest() {
                ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext();
                String[] configLocations = new String[] { "/your-beans.xml" };

Tuesday, 6 May 2014

Happy customer cocktail recipe



1 - Take a bit of Kanaban, Scrum retrospectives, XP practices and mix well.

2 - Setup your board. ( You will need an electronic board, so choose between  JIRA agile , Versionone , Leankit , etc. Remember, it's not about how big it is, but how you use it ).

3 - Setup Jenkins. You will need to build the following pipelines : 

The following to run after every commit.

Continuous build job : this is triggered every time there is a commit. It runs unit and acceptance tests against trunk.

Sonar job : If the above passed, then  it's time to check the quality of the code committed. You can use sonar and the sonar plugin for Jenkins.

The following to run every night, each depends on the success of the previous.

Continuous build job : yes again, no point in running the following if this fails.

Release jobthis creates a production release (maven release or whatever is your company policy about releases) out of your trunk(svn)/master(git) branch.

Deploy to dev job : This job automatically deploys to dev environments.

Dev System tests job : This will trigger your integration tests against dev environments.

Deploy to perf job : This job automatically deploys to performance environments.

Performance tests job : This run your JMeter tests against perf using the permormance jenkins plugin.

4 - Each business story will need to follow this process :

Pair : If the story is not trivial, do pair programming. It will speedup development and it will reduce dramatically the number of bugs.

Distill the story :  Sit with your pair, QA and the Product Owner and write down all the acceptance criteria. Ask questions here and try to cover all possible scenario.  

ATDD : Write acceptance tests first. It will not compile at first because you do not have any implementation, so write the interfaces that you need in order to make the project to compile. Run the test, it will still fail. 

TDD : Now write the test for the most external part of your code. (implement leaves first). Run the test. Implement the code to make the test pass. Test more. Implement more. Continue until the story is fully tested and implemented.

ATDD : Re run your existing acceptance tests. They should pass now.

Review : Submit the code for review. Once the code has been reviewed you can commit.

Sonar : wait for Sonar to tell you how good you and your pair are.

5 - After the Jenkins nightly pipeline is successful completed, the QA team can pick up the Release and they can deploy to their QA environment. QA will run manual, automate and exploratory tests and if bugs have been found, developers need to act immediately. 

6 - When QAs do not find bugs, the release can be deployed into UAT where the Product owners can verify and accept the stories.

7 - Once POs are happy, Ops team can deploy to Preprod in order to test the deployment scripts and the deployment instructions.

8 - Ops can deploy the release in production.

Happy customers can celebrate now.


Friday, 2 May 2014

Why you should not work extra hours

There are pros and cons in working extra hours or over time regularly, here is an attempt to list them all. Some are well known, some are taken from my experience, if you know other reasons just comment and I'll include them in the list.


You are going to introduce bugs 

Human concentration does not last for long time, and it decreases drastically if your brain doesn't rest properly.
We are already introducing bugs when we are extremely focused and well rested in the morning, so it's easy to imagine the disaster that can happen at 10PM.
8 hours of mental work a day is more than enough for your brain.

Your changes cannot be promptly reviewed 

Code reviews is an extremely powerful tool that is widely used by team in order to control code quality. It works perfectly when reviews are done immediately and you can talk face to face with your team members. It works well when it's done using tools like Gerrit, Reviewboard and so on. It works bad if every morning there are tons of lines of code to review because of nightly or extra hours commits.

Stories team estimation goes wild

One of the most painful part of any agile team is the stories estimation (less in Kanban, more in Scrum). It is painful, stressful, long and it is tiring for all the participants. Estimations are based on stories complexity and time. The time is the 8 hours per 5 days a week. Now, all this estimation gets distorted and so useless when team members regularly work extra hours. Team will get frustrated.

You can create tension between team members

One thing I noticed in teams where some members work over time, is the presence of hostilities and tension. Why is that? People that follow regular work hours can be worried about their career being compromised because they do not stay longer in the office. People who work late can see the others as non involved/interested enough on the job. Solution? simple, stick on regular hours.

You create wrong expectations

Everyone knows, you give a hand and they want your arm. You work regularly over time and your manager will start soon to expect and to count on you to stay late.

You lose a great part of your life



Sunday, 27 April 2014

Software developers by nationalities

In the last 12 years I worked closely with lots of developers coming from lots of different countries.
I though to put together a post, trying to describe the commonalities and differences I found between skills and nationalities, but then I thought It would be funnier and better(I'm lazy today) to create a simple survey and ask the developers out there and so here we go:

See result on line

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...

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;
public class SomeService {

        private String apiUsers;

        private ImmutableSet<String> acceptableAPIBUsers;

        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
class SomeServiceAccessor {

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

And use it in your unit test:

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

        private SomeService service;

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

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

        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;
public class SalaryService {

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

    private EmployeeDAO employeeDAO;

    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;
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;
public class TaxCalculator {

    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;
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;

    private SalaryService salaryService;

    private EmployeeDAO employeeDAO;

    private TaxCalculator taxCalculator;

    public void init() {

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

    public void testMaximumSalary() {
        BigDecimal annualSalary = new BigDecimal(80000);
        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.