Develop ZeroDefect API's with ZeroCode!

This post details about how you can configure your mindset and achieve 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 and etc etc.

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

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

but WHY? In my experience so far, it may be due to following factors:-

Problem Statement

1) Involvement of QA at later stage. Normally they gets on boarded 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 comes because we introduced integration test cases at later stage!

5) Load and performance Testing kicks-In at very later stage.

6) Application Profiling kicks-In at later phase when testers reports issues.

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

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

Solution Approach - Code & Automate Integration Test Cases

Once your API’s contract are ready (probably draft is also perfect, because design gets evolve 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’s.

    a)  "API Build" - Project with implementation of API’s contracts practicing TDD with unit tests. Developers own this.

    b) "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 api’s or boundary systems are not ready to integrate ).

 Later, you will just switch same test cases to run against actual test env of boundary systems/api’s. 

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 it's 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 -

A) Functionality Based Test Suites - something like Verify-ALLGET-Operations-TestSuite, Verify-ALLPOST-Operations-TestSuites, OR Verify-AccountCreationJounery-TestSuite wihch could involve account creation, fetch newly created account details, test 400, 404, 500 cases with account creation journey etc.

B) 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 100secs 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 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 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 walk-through

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

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

refer list of available versions here ZeroCode Maven Central 

2) src/test/java  - Organize integration test cases in faster ever possible way!

   2.a) /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 2.b in the solution approach section above. You will see all the details about @TargetEnv and @RunWith on the github with README.md

    

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

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

 2.c) / 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 REAME.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 API's.

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