This document discusses testing strategies for microservices at an iLottery platform built with a microservices architecture. It outlines a test pyramid with four levels of automated tests - unit tests, functional component tests, platform integration tests, and system integration tests. It also describes the tools used for different types of tests, including Spock, Groovy, Wiremock, and Geb/Spock for UI tests. Lessons learned include introducing contract-driven testing and increasing collaboration between QA and the software engineer in test role.

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!