Code & Automate - Integration Tests - Best Practices

Introduction

This article details how you can configure your mindset and achieve the possibility of developing and delivering zero defects API with TDD, Writing and automating Integration Test Cases along with Build pipeline strategy.

In projects, we always talk about code quality, and hence we scan our code against various tools like FindBug, SonarQube, we write unit test cases (min 80% coverage), we write Integration test cases, we apply profiling, etc.

We do all do this setup, with a GOAL for achieving less number of defects with quality deliverables as much as we could. Yeah?

Now, even after having these code quality gates in place, we still find defects, some basic defects which shouldn't be there at all, contract related issues, integration issues, some due to load/performance, some due to memory issues, etc. and It DOES happen!!

But WHY? In my experience so far, it may be due to the following factors.

Problem Statement

1. Involvement of QA at a later stage. Normally, they get on board when you see your code integrated and working at least locally and ready to deploy on CIT or SIT, whatever.
2. Less focus on writing Integration Test cases in the BEGINNING
3. Automation of Integration Test cases
4. Takes time to correct/update integration test cases when defects come because we introduced integration test cases at a later stage!
5. Load and performance testing kicks - at a much later stage
6. Application Profiling kicks in at a later phase when testers report issues.

You might have more points to add and in-fact, you would have addressed few of them at the right time but in general, this is what we see happening!

In order to find a solution of those 6 points listed above, please read the below approach and the framework I have used in the sample project code to make it possible. I am sure that you would easily map solutions to the above points when you read what's below.

Solution Approach - Code & Automate Integration Test Cases

Once your API’s contract is ready (probably draft is also perfect, because design gets evolved as you move on, so don't wait!)

1. Involve QA in the BEGINNING and make them comfortable with API contracts with the same comfort as of developers.
2. Create two projects of each API.
   1. "API Build" - Project with implementation of API’s contracts practicing TDD with unit tests. Developers own this.
   2. "API Integration Test" - Project with Integration Test Cases.
      Writing JSON part of this project will be owned by QA and JAVA part will be owned by developers.
      You will see below, how QA can contribute in writing up integration test cases from day 1!
      Java developer will focus on mocking up external API calls and boundaries of the system (when external APIs or systems are not ready to integrate). Later, you will just switch same test cases to run against actual test env of boundary systems/APIs.
3. Setup two Jenkins build jobs for each API (“API Build” and “API integration Test”) because I don’t want my API Build project failure because of API Integration Test project failure hence the separation. Make sense?
4. Develop both of these projects in parallel - It would be obvious that API Integration Test project will finish sooner with basic integration test cases in place and hence eventually you will end up building TDD on your Jenkins build.
5. FAIL FAST approach - Schedule (daily and then later hourly) Jenkin Builds for API Integration Test project. Initially, you will see more failures on API Integration Test projects because “API Build” is still in development mode. Which is what the intention towards FAIL FAST approach!
6. Feel Good - As the “API Build” project development progresses, you will see more tests passing on the “API Integration Tests” project. Feel good about it! YES PLEASE.
7. Write Performance Test cases - The moment you see some comfort on the “API Integration Test” build, immediately GET your QA involved in writing Performance Testing test case scenarios.
   With the framework I have used in my sample gitgub code, it is very easy to write performance test cases with its simplest ever form using JSON and yes, QA can do it very well and very quickly. They would just need NFR!
8. Introduce Integration Test Suites - Now, its time to write various Test Suites for testing logically related functionality together and independently. Think of creating various test suites, for example:
   1. Functionality Based Test Suites - something like Verify-ALLGET-Operations-TestSuite, Verify-ALLPOST-Operations-TestSuites, OR Verify-AccountCreationJounery-TestSuite which could involve account creation, fetch newly created account details, test 400, 404, 500 cases with account creation journey, etc.
   2. Performance based Test Suites - something like, Verify-GradualLoad-ALLGET-Operations-TestSuite (increase load gradually with 5 sec gap, 2 sec gap, 0.2 sec gap, etc.), Verify-ParallelLoad-ALLGET-Operations-TestSuite (increase load parallel - 100 requests in 100 secs, i.e., each request in 1 sec gap, looping twice, meaning 200 parallel requests)
9. FAIL-FAST again on Performance Test now! - See more failures on API Integration Test project for Load Test Suites. Fix issues on API Build project and reduce failures.
10. Feel Good again on Performance Test - As you fix issues, you will definitely see more confidence on your application on the performance side.
11. Add more and more tests to API Integration Tests project, Fail again, Feel good again, and keep it RUNNING!

Using the Code

I have explored an effective and efficient way of writing integration and performance test cases with an open source framework. Please follow details.

I have developed a very simple REST API using Spring Boot, Spring Data, H2 In-memory DB with Maven.

Clone sample project from my GitHub account at https://github.com/BeTheCodeWithYou/SpringBoot-ZeroCode-Integration.

Clone -> https://github.com/BeTheCodeWithYou/SpringBoot-ZeroCode-Integration.git

Once you clone, go to your local repo and run below:

mvn clean install

Check the test results in /target folder.

Running the Application

Java -jar SpringbootRestInMemoryDB-1.0.0-SNAPSHOT.jar.jar

Code Walkthrough

Once you import the project into IDE, it will look like below. Highlighted once are the integration tests related code. That’s all and easy!

1. Add dependency to your pom.xml:
   XML

   <dependency>
   <groupId>org.jsmart</groupId>
   <artifactId>zerocode-rest-bdd</artifactId>
   <version>1.2.6</version>
   <scope>test</scope>
   </dependency>

   Refer to the list of available versions at ZeroCode Maven Central.

2. src/test/java - Organize integration test cases in fastest ever possible way!

   

   1. /integrationtests - TestGetOperations.java

      As you see below, you just need to provide JSON file location, where the actual test case preset with asserts and this is the JSON, which will be created by QA as I mentioned in point 2b in the solution approach section above. You will see all the details about @TargetEnv and @RunWith on the github with README.md.

      

   2. /testconfig - Custom class which runs spring app. You will just need to write start method in your spring main class.

      

      Spring main class with start method, being called by E2eJunitRunner above:

      

   3. / testsuite - This runs the entire test suite, i.e., picking all tests under "resources/integration_tests" folder and sub-folders.

      As you see below, @EnvProperty is very interesting here. It allows you to run your test suite against multiple environments without any code change. All details are on the github with README.md file.

3. src/test/resources - Write test cases in JSON formats for your API end points with assertions.
   Plenty of variations available for assertions of the response body, headers, custom response headers, etc.

   One sample (/reintegration_tests/get/get_new_parkrunner_by_parkrunid_test.json) here from the project looks like this. You can see that request and response body can be re-used very easily.

   

4. Reports - See your test reports from the /target folder. Very interactive reports.

   

   

Thanks for your time and hope you finds this article useful as best practice for developing your APIs.

Feel free to provide comments and suggestions on improving this best practice.