Expanding API test coverage through a pipeline

Slide 1

Slide 1 text

Expanding API test coverage through a pipeline Elias Nogueira Principal Software Engineer in Test eliasnogueira

Slide 2

Slide 2 text

Disclaimer This presentation will be done (almost) in a reverse order

Slide 3

Slide 3 text

Disclaimer The Test Pyramid focus will be on the API part, not related to Unit and UI layers

Slide 4

Slide 4 text

Concept

Slide 5

Slide 5 text

Original Test Pyramid UI Tests Service Tests Unit Tests more isolation more integration faster slower

Slide 6

Slide 6 text

Ideal Test Pyramid

Slide 7

Slide 7 text

Individual APIs API API API API API API API API

Slide 8

Slide 8 text

Individual APIs API API API API API API API API We’ll assume that each API is already tested Unit Test must be done

Slide 9

Slide 9 text

Individual APIs API API API API API API API API Functional testing in each API

Slide 10

Slide 10 text

Contract and E2E testing API API API API API API API API Contract & E2E Testing

Slide 11

Slide 11 text

Contract and E2E testing API API API API API API API API Contract & E2E Testing Guarantee that they are communicating without problem

Slide 12

Slide 12 text

Contract and E2E testing API API API API API API API API Contract & E2E Testing Assure that they can be used together (e2e)

Slide 13

Slide 13 text

Recall

Slide 14

Slide 14 text

Rest-Assured http://rest-assured.io Java DSL for simplifying testing of REST based services import static io.restassured.RestAssured.*; import static org.hamcrest.Matchers.*; public class RestAssuredExampleTest { @Test public void welcome() { given(). param("name", "Elias"). when(). post("/register"). then(). body("message", is("Hello Elias")); } }

Slide 15

Slide 15 text

import static io.restassured.RestAssured.*; import static org.hamcrest.Matchers.*; public class RestAssuredExampleTest { @Test public void welcome() { given(). param("name", "Elias"). when(). post("/register"). then(). body("message", is("Hello Elias")); } } Rest-Assured http://rest-assured.io Java DSL for simplifying testing of REST based services. import libraries

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

SUT – System Under Test

Slide 20

Slide 20 text

SUT – System Under Test | Front-end We should inform a CPF * Its a Brazilian social security number If a restriction is found, show a message

Slide 21

Slide 21 text

SUT – System Under Test | Front-end Fill in loan information

Slide 22

Slide 22 text

SUT – System Under Test | Front-end CRUD operations

Slide 23

Slide 23 text

Pipeline

Slide 24

Slide 24 text

API Pipeline Health Check Contract Functional Acceptance Verify if the endpoint is alive Assert that the specs haven’t changed Assert all the criteria from the requirement + happy/sad paths Assert that the most important user scenarios still works

Slide 25

Slide 25 text

Health Check Pipeline (pyramid view) Contract Acceptance Functional

Slide 26

Slide 26 text

Enabling the Pipeline Create a way to, easily, filter the tests by their focus/function/level… @Test(groups = "functional") public void testNgGroup() { // test goes here } @Test @Tag("functional") void junitTag() { // test goes here } XML file Suite Class Suite

Slide 27

Slide 27 text

[how to] Enabling the Pipeline In the example 1. Create a strategy to filter your tests ○ Example of using groups in a test [1] 2. Create a strategy to enable the test be executed by command line ○ JUnit 5 already do it through the maven-surefire-plugin ○ We must pass the property –Dgroup=“group-name” in the command line 3. Create a pipeline as a code ○ Example using GitHub Actions [2] [1] RestrictionsFunctionalTest.java [2] test-execution.yml

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

API health-check Health Check Contract Functional Acceptance Verify it the endpoint is alive Assert that the specs haven’t changed Assert all the criteria from the requirement + happy/sad paths Assert that the most important user scenarios still works

Slide 30

Slide 30 text

heath-check Verify if the API is available If there’s no way to verify by a monitoring strategy we can make a request and validate the status code @Test(groups = "health") public void healthCheckViaActuator() { basePath = "/actuator"; when(). get("/health"). then(). statusCode(200). body("status", is("UP")); } via monitoring @Test(groups = "health") public void healthCheckViaAPI() { given(). pathParam("cpf", "81016654049"). when(). get("/restrictions/{cpf}"). then(). statusCode(200); } via API

Slide 31

Slide 31 text

[how to] health-check 1. Identify if you have a health check endpoint ○ If true find out, beyond the endpoint, any return status ○ If false, make a request to the easiest endpoint (GET?)

Slide 32

Slide 32 text

[how to] health-check In the example ● In the local project hit http://localhost:8088/actuator/health ○ You’ll see the health status ● See the implemented tests on: ○ CreditHealthCheckTest [1] ● Items to pay attention: ○ It’s getting the health context from the file because it does not have the /api/v1 to hit the actuator endpoint [1] CreditHealthCheckTest.java

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

API contract Health Check Contract Functional Acceptance Verify it the endpoint is alive Assert that the specs haven’t changed Assert all the criteria from the requirement + happy/sad paths Assert that the most important user scenarios still works

Slide 35

Slide 35 text

● It’s the name given to the pact between producer and consumer ● Ensures that API changes do not invalidate consumption: ● path ● parameters ● sending data (request) ● return data (response body) ● json-schema is a contract that defines the expected data, types and formats of each field contract

Slide 36

Slide 36 text

{ "name": "Elias", "age": 37 } { "$schema": "http://json-schema.org/draft-04/schema#", "type": "object", "properties": { "name": { "type": "string" }, "age": { "type": "integer" } }, "required": [ "name", "age" ], "additionalProperties": false } json-schema

Slide 37

Slide 37 text

Slide 38

Slide 38 text

{ "name": "Elias", "age": 37 } { "$schema": "http://json-schema.org/draft-04/schema#", "type": "object", "properties": { "name": { "type": "string" }, ”age": { "type": "integer" } }, "required": [ "name", "age" ], "additionalProperties": false } both attributes must be present json-schema

Slide 39

Slide 39 text

{ "name": "Elias", "age": 37 } { "$schema": "http://json-schema.org/draft-04/schema#", "type": "object", "properties": { "name": { "type": "string" }, "age": { "type": "integer" } }, "required": [ ”name", ”age" ], "additionalProperties": false } json-schema no other attributes are allowed

Slide 40

Slide 40 text

[how to] contract 1. Create schema files ○ We can use online tools to create if it’s not available 2. Create a test making a request and validating the json schema ○ Add json-schema-validator library ○ Statically import the matcher ○ Use the matcher against json schema file

Slide 41

Slide 41 text

[how to] contract In the example ● See the implemented tests on: ○ RestrictionsContractTest.java [1] ○ SimulationsContractTest.java [2] ● Items to pay attention: ○ The validation is done by the matcher matchesJsonSchemaInClasspath, checking the response body with the json schema file ○ If you want to see different API enable the test contractOnV2 on RestrictionsContractTests [1] RestrictionsContractTest.java [2] SimulationsContractTest.java

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

API functional Health Check Contract Functional Acceptance Verify it the endpoint is alive Assert that the specs haven’t changed Assert all the criteria from the requirement + happy/sad paths Assert that the most important user scenarios still works

Slide 44

Slide 44 text

functional Validate positive and negative scenarios (happy and sad path) @Test(groups = {"functional"}) public void existentSocialSecirityNumber() { given(). pathParam("cpf", "66414919004"). when(). get("/simulations/{cpf}"). then(). statusCode(200). body( "id", equalTo(1), "name", equalTo("Oleksander"), "cpf", equalTo("66414919004"), "email", equalTo("[email protected]"), "amount", equalTo(11000f), "installments", equalTo(3), "insurance", equalTo(true) ); } data validation

Slide 45

Slide 45 text

[how to] functional 1. Create the tests avoiding repetitions ○ Use Test Data Factories and Data Driver in your advantage 2. Apply the strategy you like ○ All tests in the same class ○ One class per test

Slide 46

Slide 46 text

[how to] functional In the example ● See the implemented tests on: ○ RestrictionsFunctionalTest.java [1] ○ SimulationsFunctionalTest.java [2] ● Items to pay attention: ○ The tests are using a soft assertion for the body validation ○ MessageFormat class is used to properly concatenate String ○ SimulationsFunctionalTests is using Test Data Factory, Builders for the model object and Data Driven [1] RestrictionsFunctionalTests.java [2] SimulationsFunctionalTests.java

Slide 47

Slide 47 text

No content

Slide 48

Slide 48 text

Assert all the criteria from the requirement + happy/sad paths API acceptance Health Check Contract Functional Acceptance Verify it the endpoint is alive Assert that the specs haven’t changed Assert that the most important user scenarios still works

Slide 49

Slide 49 text

Testing from the user's perspective ● Access the page and make the restriction search by the CPF ● Insert a credit simulation

Slide 50

Slide 50 text

acceptance (e2e) @Test(groups = "e2e") public void completeSimulation() { new RestrictionsClient().queryRestrictionAndReturnNotFound(); new SimulationsClient().submitSuccessfulSimulation(); }

Slide 51

Slide 51 text

No content

Slide 52

Slide 52 text

[how to] acceptance (e2e) 1. Create the tests avoiding repetitions ○ Use Request and Response Specifications ○ Try to break out in reusable methods common actions 2. Do the User Journey ○ The few most important user journeys must run before the functional tests https://martinfowler.com/articles/practical-test-pyramid.html#RestApiEnd-to-endTest

Slide 53

Slide 53 text

[how to] functional In the example ● See the implemented tests on: ○ FullSimulationE2ETest.java [1] ● Items to pay attention: ○ There’s a utility class with the suffix Client in order to have an easy way to make request and response calls ○ The request and response calls are Specification Re-use [2] created to reuse these actions ○ See also the packages client [3] and specs [4] [1] FullSimulationE2ETest.java [2] https://github.com/rest-assured/rest-assured/wiki/usage#specification-re-use [3] client package [4] specs package