Testing microservices is challenging. Dividing a system into components (à la microservices) naturally creates inter-component dependencies, and each service has its own performance and fault-tolerance characteristics that need to be validated during development, the QA process, and continually in production. Attend this meetup to learn about the theory, techniques, and practices needed to overcome this challenge. You will: • Get an introduction to the challenges of testing distributed microservice systems • Learn how to isolate tests within a complex microservice ecosystem • Hear about several tools for automating vulnerability and security scanning for code, dependencies, and deployment artifacts

1. Testing Java Microservices:
From Development to Production
Abraham Marin-Perez | Daniel Bryant

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 are we?
@danielbryantuk
Tech Consultant and Writer
Product Architect at Datawire
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. Isolating Parts: No Isolation
Third Party

11. Isolating Parts: Unowned Components
Third Party

12. Test Doubles

13. 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)

20. JUnit Example

21. 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

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

24. Isolating Parts: Service Interaction
Third Party

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

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

27. Consumer-Driven Contracts

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

29. 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

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

31. Components

32. Isolating Parts: Single Service
Third Party

33. Isolating Parts: Single Service

34. Isolating Parts: Single Service
Test
Doubles

35. Isolating Parts: Single Service

36. Isolating Parts: Single Service
+

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

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

39. Isolating Parts: Technicalities
Third Party

40. Isolating Parts: Technicalities
Test the Real Thing

41. Isolating Parts: Technicalities

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

43. Isolating Parts: Data

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

45. Isolating Parts: Data

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

48. Security: Code

49. Security: Dependencies

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

51. 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

52. Thanks!
Some code samples:
https://github.com/orgs/continuous-delivery-in-java
(with more coming soon!)