Dividing a system into a series of services that communicate over an unreliable network naturally creates challenging conditions for testing inter-service interactions. Each service has its own functional requirements, and performance and fault-tolerance characteristics that need to be validated during development, the QA process, and continually in production. Join Daniel Bryant to learn about the theory, techniques, and practices that can help to overcome these challenges. Overview and learning Outcomes: • Introduction to the challenges of testing distributed microservice systems • Learn tactics for isolating tests within a complex microservice ecosystem • Join a whistle-stop tour of consumer-driven contract testing and API simulation • Understand where to implement fault-injection within doubles in order to validate nonfunctional requirements in development and QA • Understand the benefits of continually validating microservice systems running in production

1. Testing Microservices:
From Development to Production
Daniel Bryant
@danielbryantuk

2. tl;dr
● Testing microservices brings additional challenges
● Pay special attention to integration surfaces
● Isolate services for loosely coupled tests
● Include tests that resemble production
● Make security testing a first-class citizen

3. Who am I?
@danielbryantuk
Product Architect at Datawire
Consultant, Writer
Java Champion, Conference Tourist
@abrahammarin
Developer, Consultant, Writer
Associate of Equal Experts
Software Plumber

4. Types of tests
From Agile Testing, by Lisa Crispin and Janet Gregory

5. Challenges
● Cannot share a single environment: test locally
● Full ecosystem unsuitable for local testing
● Lack of control over third-party dependencies

6. Isolation

7. Isolating Parts
Third Party

8. Isolating Parts
Third Party

10. https://medium.com/@copyconstruct/testing-microservices-the-sane-way-9bb31d158c16
Software
Testing Funnel

12. Isolating Parts: No Isolation
Third Party

13. Isolating Parts: Unowned Components
Third Party

14. Test Doubles

15. Test Doubles
Dummy objects: passed around but never actually used.
Fake objects: working implementations not suitable for production
Stubs: provide canned answers to calls made during the test
Spies: stubs that also record some information based on how they were called.
Mocks: objects pre-programmed with expectations which form a specification of the
calls they are expected to receive.
Virtualisations: emulation of services, with expectations (not suitable for production)
https://martinfowler.com/articles/mocksArentStubs.html

22. JUnit Example

23. API Simulation Thoughts
● Useful when a dependency is “expensive” to
access or tricky to mock
● Facilitates error handling tests when dependency
failure modes are challenging to recreate
● Simulations can be fragile and/or complicated

24. Use simulations appropriately...
Sometime you need the real thing

26. Isolating Parts: Service Interaction
Third Party

27. Focused on
service/function
Focused on
system
Contract Tests

28. API Contracts
APIs are service contracts
Many are producer-driven
It’s possible to design outside-in:
Consumer-Driven Contracts

29. Consumer-Driven
Contracts

30. Consumer-Driven Contracts
https://www.baeldung.com/pact-junit-consumer-driven-contracts

32. Consumer-Driven
Contracts

33. Consumer-Driven Contract Frameworks
https://docs.pact.io/ https://cloud.spring.io/spring-cloud-contract/

34. Consumer-Driven Contract Thoughts
● Great in low trust or low communication organisations
○ Act as a cue for a conversation
● Can be used to implement “TDD for the API”
● Resource intensive to create and maintain

35. https://bit.ly/2p68gBS

36. Components

37. Isolating Parts: Single Service
Third Party

38. Isolating Parts: Single Service

39. Isolating Parts: Single Service
Test
Doubles

40. Isolating Parts: Single Service

41. Isolating Parts: Single Service
+

42. Isolating Parts: Single Service
Fault Tolerance
Test double configured to fail

43. https://technology.cap-hpi.com/blog/unit-testing-what-benefits-you-can-reap/

44. Isolating Parts: Technicalities
Third Party

45. Isolating Parts: Technicalities
Test the Real Thing

46. Isolating Parts: Technicalities

47. Isolating Parts: Data
Test Data
● Low Volume
● Low Diversity
Production Data
● High Volume
● High Diversity

48. Isolating Parts: Data

49. Isolating Parts: Data
Marín
Argüelles
d’Hopital
Garçon
Castaña
Strauß
Fønss
Bård
かほる
Александр
สมชาย
Φραγκόπουλος

50. Isolating Parts: Data

51. Isolating Parts: Data
a а
“a” “azǔ”
U+0061 U+0430

53. www.owasp.org
https://www.owasp.org/index.php/C
ategory:OWASP_Top_Ten_Project

54. Security: Code

55. Security: Dependencies

56. Security: Container Images
github.com/arminc/clair-scanner

57. Wrapping Things Up

58. Conclusion
● Testing microservices brings additional challenges
● Pay special attention to integration surfaces
● Isolate services for loosely coupled tests
● Include tests that resemble production
● Make security testing a first-class citizen

59. Thanks!
Feel free to ask questions...
@danielbryantuk

60. Bonus

61. Semantic Txns / Synthetic Monitoring
https://martinfowler.com/bliki/SyntheticMonitoring.html

62. https://martinfowler.com/articles/microservice-testing/#conclusion-summary