FlexiSAF Brown Bag Series: The relevance of Integration Testing

According to a zdnet.com article, about 70% of all software projects fail due to a number of factors. Lack of well defined project requirements being a major one. Another being a disregard of standard software engineering techniques – which were borne out of experiments, analysis of accumulated data over decades.

 

Our focus in this article is on the latter. These techniques are being refined continuously with new discoveries gained through experience, with the main aim of improving code quality – the building blocks of any software program.

 

Typical software quality assurance checks include static code analysis, which according to the Java Magazine, reduces code defects by 44%, Test Driven Development (TDD) reduces defects by 37% and formal inspection comes in at 60%. And of course, these figures are not additive, having the formal inspection and static code analysis in check does not mean 100% defects free code.

 

What is Integration testing all about?

 

IntegrationTest or itest is a crucial part of TDD. Let’s think of this analogy, imagine we want to build a pipe to carry water from a reservoir to a treatment and purification facility. Any form of external integration means introducing another point of failure. We’ll have to add extra measures to ensure those joints are free of leakages and generally, our pipe remains in good quality. As abstract as it may sound, scenarios like these are very real and practical in a software engineering process.

 

ITests ensure your software plays along well with external sources, from database connectivity, a messaging app API and so on.

 

Enough talk, let’s write some integration tests.

 

Looking at a simple JAX-RS API

 

Code snippets following

 

@Path(“sessions”)

@Produces(MediaType.APPLICATION_JSON)

@Consumes(MediaType.APPLICATION_JSON)

@Stateless

public class SessionsResource {

 

   @EJB

   private SchoolConfigMngrLocal schoolConfigMngr;

 

   @GET

   public Response getSessions() {

       List<SessionDto> sessionDtos = mapToSessionDtos(schoolConfigMngr.getSession());

       return Response.ok(sessionDtos).build();

   }

   

   @GET

   @Path(“{id}”)

   public Response getSession(@PathParam(“id”) String sessionId) {

       Session session = schoolConfigMngr.getSession(sessionId);

       SessionDto sessionDto = mapToSessionDto(session);

       

       return Response.ok(sessionDto).build();

   }  

}

 

The SessionResource class is a stateless EJB which communicates to another EJB, the SchoolConfigMngrLocal. This provides the implementation for fetching session from the DB using an entity manager. Entity managers too, require an integration tests of their own. We plan to cover those in upcoming articles.  Now we are interested in writing test for API endpoints in a RESTFul architecture.

 

Using JUnit library and other standard java libraries, a typical integration test for the code snippet  is show below.

 

public class SessionResourceTest {

 

   private Client client;

   private WebTarget target;

   

   @Before

   public void init() {

       this.client = ClientBuilder.newClient();

       this.target = client.target(“http://localhost:8080/api/v1/sessions”);

   }

   

   @Test

   public void getSessions() {

       Response sessions = this.target.request().get();

       assertThat(sessions.getStatus(), is(200));

   }

   

   @Test

   public void getSession() {

       JsonObject sessionObject = this.target.path(“2015/2016”)

               .request(MediaType.APPLICATION_JSON)

               .get(JsonObject.class);

       

       assertTrue(sessionObject.getString(“sessionId”).contains(“2015/2016”));

   }

}

 

What we have covered can then be a part of a bigger picture of the production pipeline. That is, a section that always needs to be checked to ascertain its functionality when delivering the service to the customer/end-user.