Konstantinos Sidiropoulos - Testing microservices a real example
- 1. Testing Microservices-a real example May 24
- 2. 2 iLottery PLatform ● iLottery Platform built in a microservices architecture ● Java, Spring framework, Cassandra ● Kubernetes, Docker 2
- 3. 3 Test Pyramid 3 ● Stage 1: Automated Unit Tests ● Stage 2: Functional Component tests- Automated tests against a service with ALL its dependent services (Platform AND 3rd-party mocked) ● Stage 3: Platform Integration Tests - Automated Tests run against the platform (without web app or admin portal) and 3rd- party ONLY mocked ● Stage 4: System integration tests - Automated tests of our platform with web app and admin but 3rd-parties are mocked.
- 4. 4 Unit tests ● Technology facing tests ● These are tests against Java classes. ● The boundary is the class ● No build can be done if line, branch, complexity coverage is less than 80% 4
- 5. ● Functional component tests- Automated tests against a service with ALL its dependent services (Platform AND 3rd-party mocked) ● Web app, Admin Portal and backend services are tested in isolation ● They are triggered with every merge to master ● If these tests fail then no version is created, so service is not deployed 5 Functional Component Tests 5
- 6. ● Platform Integration Tests - Automated Tests run against the platform (without web app or admin portal) and 3rd-party ONLY mocked ● Tests that check the integration of platform services ● They run every 3 hours from 8:00 till 20:00 UK time ● They run against latest stable versions of services (i.e. services where functional component tests are passed) 6 Platform Integration Tests 6
- 7. ● These are E2E tests ● Automated Tests run against the Excalibur platform (with webapp or admin portal) and 3rd-party ONLY mocked ● They run every 3 hours from 8:00 till 20:00 UK time ● They run against latest stable versions of services (i.e. services where functional component tests are passed) 7 System Integration Tests 7
- 8. ● These are tests that check how the platform behaves in case of errors in http calls ● Wiremock was used with its proxy ability ● Failure injection of wiremock was used ● They run against latest stable versions of services (i.e. services where functional component tests are passed) 8 Reconciliation tests 8
- 9. { "request" : { "urlPath" : "/api/play", "method" : "POST" }, "response" : { "status" : 504 } } 9 Reconciliation tests 9
- 10. 10 Tools used ● For UI tests Geb(http://www.gebish.org/), Spock test framework were used ● Web app and admin functional component tests ● System Integration Tests 10 ● For API testing Spock test framework, groovy REST client and a custom framework wascreated ● Wiremock was used for stubbing external dependencies ● Functional Component Tests for BE services ● Platform Integration tests
- 11. 11 Software Engineer in Test ● A developer role focusing in testability of the platform ● Implement automated tests ● Review automated tests implemented by devs ● Implement test tooling ● Responsible for test environments (Kubernetes cluster in AWS) ● Implement test APIs 11
- 12. 12 Lessons learned ● Introduce Contract driven testing- Spring Cloud Contract integrates with Spock and Wiremock ● QA and SET need more collaboration 12 ● Layered test suites parallelized testing and decreased execution time ● Less UI tests meaned increased stability
- 13. Thank you!