Testing Java Microservices:
From Development to Production
Abraham Marin-Perez | Daniel Bryant
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
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
Types of tests
From Agile Testing, by Lisa Crispin and Janet Gregory
Challenges
● Cannot share a single environment: test locally
● Full ecosystem unsuitable for local testing
● Lack of control over third-party dependencies
Isolation
Isolating Parts
Third Party
Isolating Parts
Third Party
Isolating Parts: No Isolation
Third Party
Isolating Parts: Unowned Components
Third Party
Test Doubles
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)
JUnit Example
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
Use simulations appropriately...
Sometime you need the real thing
Isolating Parts: Service Interaction
Third Party
Focused on
service/function
Focused on
system
Contract Tests
API Contracts
APIs are service contracts
Many are producer-driven
It’s possible to design outside-in:
Consumer-Driven Contracts
Consumer-Driven Contracts
Consumer-Driven Contract Frameworks
https://docs.pact.io/ https://cloud.spring.io/spring-cloud-contract/
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
https://bit.ly/2p68gBS
Components
Isolating Parts: Single Service
Third Party
Isolating Parts: Single Service
Isolating Parts: Single Service
Test
Doubles
Isolating Parts: Single Service
Isolating Parts: Single Service
+
Isolating Parts: Single Service
Fault Tolerance
Test double configured to fail
https://technology.cap-hpi.com/blog/unit-testing-what-benefits-you-can-reap/
Isolating Parts: Technicalities
Third Party
Isolating Parts: Technicalities
Test the Real Thing
Isolating Parts: Technicalities
Isolating Parts: Data
Test Data
● Low Volume
● Low Diversity
Production Data
● High Volume
● High Diversity
Isolating Parts: Data
Isolating Parts: Data
Marín
Argüelles
d’Hopital
Garçon
Castaña
Strauß
Fønss
Bård
かほる
Александр
สมชาย
Φραγκόπουλος
Isolating Parts: Data
www.owasp.org
https://www.owasp.org/index.php/C
ategory:OWASP_Top_Ten_Project
Security: Code
Security: Dependencies
Security: Container Images
github.com/arminc/clair-scanner
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
Thanks!
Some code samples:
https://github.com/orgs/continuous-delivery-in-java
(with more coming soon!)

Testing Java Microservices: From Development to Production

Editor's Notes

  • #6 The quadrants hint at a number of challenges, which for microservices is even harder because… (and then bullet points) Full ecosystem: too large, too diverse, too evolving
  • #8 to avoid gaps: expanding levels (concentric dotted lines, brittle, inefficient) chained levels (overlapping dotted lines, requires more management)
  • #9 All about trade-offs to avoid gaps: expanding levels (concentric dotted lines, brittle, inefficient) chained levels (overlapping dotted lines, requires more management)
  • #10 the whole is more than the sum of the parts, need to avoid silos
  • #11 no isolation, but closest to user experience. Necessary evil?
  • #12 biggest fully-controlled test. Need to use test doubles for unowned components Try to find better word for unowned
  • #25 to avoid gaps: expanding levels (concentric dotted lines, brittle, inefficient) chained levels (overlapping dotted lines, requires more management)
  • #33 Expect people to know this, just in case. Back-up: DBUnit, Utilis Prepare for anecdotes
  • #34 Expect people to know this, just in case. Back-up: DBUnit, Utilis Prepare for anecdotes
  • #35 Expect people to know this, just in case. Back-up: DBUnit, Utilis Prepare for anecdotes
  • #36 Expect people to know this, just in case. Back-up: DBUnit, Utilis Prepare for anecdotes
  • #37 QPid works with AMQP 1.0 ActiveMQ as well, but only later versions (5.8 or later)
  • #40 Mention Franck Pachot’s talk about how SQL varies
  • #52 “Copy” tl;dr Extra challenges when workin with microservice Test doubles, options Careful with Long-running queries, different tools for isolation,e tc. (one liner) security