This document discusses strategies for testing microservices. It begins with an overview of manual vs automated testing and challenges of testing software. The goal of testing is to develop, test, and deploy without breaking the system. Unit testing is good for complex logic but not enough to ensure functionality. Integration testing tests interfaces and is fast enough on modern computers. Microservices require loose coupling and independent deployability. The document illustrates integration testing between services and discusses issues with mocks. It proposes using consumer driven contracts and API documentation to test between services. Other strategies discussed include canary deployments with service meshes and message brokers to test at scale with real data.

1. Christoph Ebeling – Managing Director
April 21, 2022
TESTING MICROSERVICES

2. AGENDA
‣ Quick overview on testing strategies
‣ Evaluating their eligibility for cloud microservices deployments
‣ Sharing two specific strategies for microservice testing

3. COMPARING MODES OF TESTING
MANUAL VS. AUTOMATED
Regression Documentation Code quality
FAST IN THE
SHORT RUN
FAST IN
THE
LONG
RUN
Manual testing can be faster in the short run, however:

4. WHY TESTING SOFTWARE CAN BE CHALLENGING
Ø Tooling
Ø Slow CI Servers
Ø Lack of knowledge about testing framework
Ø Too much effort for low ROI
Ø Bad software architecture / code is hard to
test

5. WHAT IS THE GOAL OF ALL THIS TESTING?
DEVELOP
TEST
DEPLOY

6. CAN WE
DEPLOY
WITHOUT
BREAKING
THE SYSTEM?

7. WHAT DOES
TESTABLE
CODE LOOK
LIKE?

8. EXAMPLE
▸Text
class User {
int id;
public float getMonthlyNetSpendings() {
ArrayList<Order> orders = OrderService.findByUserId(this.id);
float amount = 0;
for (Order order: orders) {
amount += order.getAmount();
}
return amount;
}
}
Needs Mock
Net or Gross?

9. TEST TYPES
1 Fast execution
2
3
4
Unit test
Good for complex logic / high
cyclomatic complexity
Not sufficient to ensure software is
working
High effort to maintain
Integration testing
Test the whole application
E2E test / Functional Test
Enables us to deploy with confidence
Hard to cover all edge cases
Painful to write and maintain
Slow
1
2
3
4
5
What would it look like in
a microservice
environment?

10. EXAMPLE
▸Text
class User {
int id;
public float getMonthlyNetSpendings() {
ArrayList<Order> orders = OrderService.findByUserId(this.id);
float amount = 0;
for (Order order: orders) {
amount += order.getAmount();
}
return amount;
}
}
LET’S TAKE A CLOSER LOOK
Needs Mock
Net or Gross?

11. TEST TYPES
1 Fast execution
Unit testing
2
Good for complex logic / high
cyclomatic complexity
3
Not sufficient to ensure software is
working
4 High effort to maintain
Integration testing E2E test / Functional testing
Test the whole application
1
Enables us to deploy with confidence
2
Hard to cover all edge cases
3
Painful to write and maintain
4
Slow
5
1 Tests a large part of the application,
including interfaces
2
Is still fast enough on modern
computers

12. REQUIREMENTS FOR A MICROSERVICE ARCHITECTURE
SERVICES ARE LOOSELY COUPLED.
CAN BE INDEPENDENTLY DEPLOYED.
TEAMS MAY WORK AT DIFFERENT TIMES, DIFFERENT LOCATIONS, NOT ALWAYS ABLE TO COMMUNICATE.
1
2
3

13. ILLUSTRATION OF MICROSERVICE INTEGRATION TESTING
SERVICE C
SERVICE B
SERVICE A
SERVICE A
TEST
Get
/api-endpoint-1
Post /api-endpoint-2
New feature needs to get
new information from
Service C
Get
/api-endpoint-2
NOT
IMPLEMENTED
CHANGE CAN’T BE MERGED
DEAR TEAM C,
WE’VE CREATED A NEW FEATURE BUT CAN’T DEPLOY
CAUSE YOU’RE MISSING AN API ENDPOINT. PLEASE
CHECKOUT MY BRANCH, THEN RUN MY NEW
CONTAINER, DEPLOY MY NEW FANCY MONGO DB, RUN
SERVICE TEST A AND MAKE SURE EVERYTHING IS FINE.
IT WOULD BE SWEET IF YOU COULD ALSO TEST THE
ERRORS FOR ME. PS: PLS DON’T FORGET TO LOAD MY
FIXTURES, RUN MIGRATION…OH AND HEY, SOMETIMES
SERVICE TEST A TIMES OUT, JUST RERUN IT. IN CASE OF
ANY PROBLEMS FEEL FREE TO HIT UP OUR INTERN.
TEAM A
TEAM C

14. I WANT MY MOCK BACK!!!
(But this time we do it better……………I promise!!)

15. WHY WE DIDN’T LIKE MOCKS IN THE FIRST PLACE?
Ø The mocked API could have a different interface
Ø The mocked API could give different results
Ø When the mocked API changes, we won’t notice

16. SERVICE C
SERVICE B
SERVICE A
SERVICE A TEST Post /api-endpoint-2
New feature needs to get
new information from
Service C
CHANGE CAN’T BE MERGED
TEAM A
TEAM C
API MOCK
DEAR TEAM C,
WE’VE CREATED A NEW FEATURE. I ALREADY TESTED IT WITH
A MOCK (IT WORKS LIKE A CHARM) AND ATTACHED YOU THE
LATEST SWAGGER FILES AS WELL AS MY PAYLOAD AND
EXPECTED JSON. PLS WRITE A UNIT TEST FOR YOUR API,
MAKE IT GREEN, AND LET ME KNOW WHEN YOU’RE DONE.
UNIT TEST
Consumer Driven Contracts

17. RECAP
WHAT DO WE KNOW SO FAR ?
Ø We covered the business logic of our single services.
Ø We know the services and their compatibility.
Ø We (hopefully) covered all edge cases that our Devs could think about.

18. WHAT STILL NEEDS TO BE COVERED
WHAT DO WE NOT KNOW ?
Ø Will it work on scale?
Ø Will it work with real user data?
Ø Is there anything our automated tests did not consider?

19. SERVICE C (V1)
SERVICE B
SERVICE A
SERVICE A TEST Post /api-endpoint-2
CHANGE CAN’T BE MERGED
SERVICE C (V2)
Splits traffic
SERVICE C
Canary deployment with service mesh

20. SERVICE C
SERVICE B
SERVICE A
SERVICE A TEST Post /api-endpoint-2
CHANGE CAN’T BE MERGED
Message Broker
MESSAGE
BROKER

21. SERVICE C (V1)
SERVICE B
SERVICE A
SERVICE A TEST Post /api-endpoint-2
CHANGE CAN’T BE MERGED
Canary Deployment with message broker
MESSAGE
BROKER
SERVICE C (V2)
Both get 100% of the traffic

22. ANY QUESTIONS

23. CONTACT DETAILS