Uploaded byAhmed Misbah
Microservice test strategies for applications based on Spring, K8s and Istio
The document discusses different types of tests for microservices including unit tests, component tests, out-of-process component tests, and end-to-end tests. It provides details on implementing each type of test for a Spring-based microservice application deployed on Kubernetes and using Istio. The tests will utilize tools like JUnit, Mockito, WireMock, and Liquibase. Test coverage targets are outlined with unit tests aiming for 100% coverage and out-of-process and end-to-end tests each covering 20-10% of code.
More Related Content
Similar to Microservice test strategies for applications based on Spring, K8s and Istio
Microservice test strategies for applications based on Spring, K8s and Istio
- 1. Microservice Test Strategiesfor application based on Spring, K8s and Istio Ahmed Misbah
- 2.
- 3. Microservice Test Pyramid •As per the guide below: https://martinfowler.com/articles/microservice- testing/ the following tests will be implemented: 1. Unit Tests (Developers): Purpose of these tests is to ensure that each class/method works right independently 2. Components Tests (Developers): Purpose of these tests is to test that all classes in the JAR work right together independent of any external component or service
- 4. Microservice Test Pyramid 3.Out-of-process Component Tests on Core Microservices only (Developers): Purpose of these tests to ensure that the microservice works right on K8s and communicates correctly with its DBs and other APIs 4. E2E Tests (QA): Purpose of E2E tests are to test behavior and functionally of APIs fully integrated
- 5. Core Microservice Component Diagram Istio- Envoy - Sidecar Proxy K8s - Pod JAR – Spring Boot K8s - Service Spring MVC - Controller Spring Bean - Service Spring Data - Repository JPA/Hibernate - ORM Utilities
- 6. Some Data storeon the cloud Some Driver (e.g. API composer, another Microservice using Envoy) Some 3rd party API Istio - Envoy - Sidecar Proxy K8s - Pod JAR – Spring Boot K8s - Service Spring MVC - Controller Spring Bean - Service Spring Data - Repository JPA/Hibernate - ORM Utilities Core Microservice Integration
- 7. Some Driver (e.g.API composer, another Microservice through Envoy or OSP Istio - Envoy - Sidecar Proxy K8s - Pod JAR – Spring Boot K8s - Service Spring MVC - Controller Spring Bean - Service Spring Data - Repository JPA/Hibernate - ORM Utilities Core Microservice Unit Tests Some Data store on the cloud Some 3rd party API
- 8. Core Microservice UnitTests Spring MVC - Controller Spring Bean - Service Spring Data - Repository JPA/Hibernate - ORM Utilities (Mock) Unit tests Service (Mock) Data Store (Stub) Unit tests Unit tests Repository (Mock)
- 9. Core Microservice UnitTests • Unit tests will run in Gitlab job • Tests will be part of the Spring Boot application • Junit 5 will be used • Mockito will be used for mocking • Controller tests will use @WebMvcTest annotation: https://reflectoring.io/spring-boot-web-controller-test/ • Repository tests will use @DataTestJPA annotation, which implicitly used H2 and tests ORM as well: https://reflectoring.io/spring-boot-data-jpa-test/ • Liquibase will be used to create schemas at the start of each test class • Sprint @Sql annotation will be used to remove and insert data before each test case: https://www.javarticles.com/2016/02/spring-sql-annotation- example.html
- 10. Some Data storeon the cloud Some Driver (e.g. API Composer, another Microservice through Envoy) Some 3rd party API Istio - Envoy - Sidecar Proxy K8s - Pod JAR – Spring Boot K8s - Service Spring MVC - Controller Spring Bean - Service Spring Data - Repository JPA/Hibernate - ORM Utilities Core Microservice Component Tests
- 11. Core Microservice ComponentTests Spring MVC - Controller Spring Bean - Service Spring Data - Repository JPA/Hibernate - ORM Utilities Component tests Data Store (Stub) Web server (Stub)
- 12. Core Microservice ComponentTests • Component tests will run in Gitlab job • Tests will be part of the Spring Boot application • Junit 5 will be used • Tests will use @SpringBootTest annotation • REST/SOAP APIs will be stubbed using WireMock: https://www.baeldung.com/introduction-to- wiremock
- 13. Core Microservice ComponentTests • MySQL will be stubbed using H2 • Liquibase will be used to create schemas at the start of each test class • Sprint @Sql annotation will be used to remove and insert data before each test case: https://www.javarticles.com/2016/02/spring- sql-annotation-example.html
- 14. Core Microservice ComponentTests • Any other data store will be stubbed using an embedded version of it: – https://www.baeldung.com/spring-embedded- redis – https://www.baeldung.com/spring-boot- embedded-mongodb • @TODO Need to check how we will provision test data in each NoSQL store
- 15. Some Driver (e.g.API composer, another Microservice through Envoy) Istio - Envoy - Sidecar Proxy K8s - Pod JAR – Spring Boot K8s - Service Spring MVC - Controller Spring Bean - Service Spring Data - Repository JPA/Hibernate - ORM Utilities Core Microservice Out-of-process Component Tests Some Data store on the cloud Some 3rd party API
- 16. Out-of-process Component Tests Istio - Envoy- Sidecar Proxy K8s - Pod JAR – Spring Boot K8s - Service Spring MVC - Controller Spring Bean - Service Spring Data - Repository JPA/Hibernate - ORM Utilities Core Microservice Out-of-process Component Tests Some Data store on the cloud Some 3rd party API
- 17. Core Microservice Out-of-process ComponentTests • Out-of-process Component Tests will not be part of the Spring Boot application under test and will be in a separate project • There will be one project for all core microservice out-of-process component tests • The tests will be separated by means of Spring/Maven profiles. Tests will cover happy/unhappy scenarios for whole core microservice
- 18. Core Microservice Out-of-process ComponentTests • Before executing the out-of-process component tests in a gitlab job, the core microservice will be deployed to K8s cluster • Test drivers will be written using REST Assured or Spring REST Template • Liquibase will not be used to create schemas at the start of each test class, as these scripts will be executed in each microservice when it starts
- 19. Core Microservice Out-of-process ComponentTests • Sprint @Sql annotation will be used to remove and insert data before each test case: https://www.javarticles.com/2016/02/spring- sql-annotation-example.html @TODO Need to check how we will provision test data in each NoSQL store
- 20. API Composers ComponentDiagram Istio - Envoy - Sidecar Proxy K8s - Pod JAR – Spring Boot K8s - Service Spring MVC - Controller Spring Bean - Service Utilities
- 21. API Gateway (Ambassador) CoreMicroservices Istio - Envoy - Sidecar Proxy K8s - Pod JAR – Spring Boot K8s - Service Spring MVC - Controller Spring Bean - Service Utilities API Composers Integration
- 22. API Gateway (Ambassador) CoreMicroservices Istio - Envoy - Sidecar Proxy K8s - Pod JAR – Spring Boot K8s - Service Spring MVC - Controller Spring Bean - Service Utilities API Composers Unit Tests
- 23. API Composers UnitTests Spring MVC - Controller Spring Bean - Service Utilities (Mock) Unit tests Service (Mock) Unit tests
- 24. API Gateway (Ambassador) CoreMicroservices Istio - Envoy - Sidecar Proxy K8s - Pod JAR – Spring Boot K8s - Service Spring MVC - Controller Spring Bean - Service Utilities API Composers Component Tests
- 25. API Composers ComponentTests Spring MVC - Controller Spring Bean - Service Utilities Component tests Web server (Stub)
- 26. E2E Tests E2E Tests APIGateway (Ambassador) API Composer (s) Core Microservices K8s Some Data store on the cloud Some 3rd party API
- 27. E2E Tests • E2Etests will run as a separate Robot Framework project in the CI/CD pipeline in Gitlab • There will be one project for all E2E tests • The tests will be separated by means of profiles. Tests will cover happy/unhappy scenarios for an endpoint or user story
- 28. AN Microservice CodeCoverage E2E (~ 10%) Out-of-Process Component Tests (~ 20%) Component Tests (~ 50%) Unit Tests ( ~ 100%) Source: https://learning.oreilly.com/library/view/the-clean- coder/9780132542913/ch08.html
- 29. Microservice Test Coverage •Test coverage will only be a measure for Out-of- process component tests and E2E tests • Minimum test coverage should be based upon acceptance criteria of user story. This will include all/most positive and negative scenarios • For unit and component tests, we must take care that code coverage can be a deceiving measure of quality of tests. Test design techniques should be used for designing test cases.