When enterprise organizations adopt microservices, containers, and cloud native development, the technologies and architectures may change, but the fact remains that we all still add the occasional bug to our code. The main challenge you now face is how to perform integration or end-to-end testing without spinning up all of your microservices locally and driving your laptop fans into high speed! Join me for a tour of testing microservices using a series of Java applications as a case study. You will learn everything about effective unit testing with mocks, using TestContainers for dependency testing, and using Telepresence to extend your local testing environment into the cloud. Learn when to use each type of test and tooling based on your use case and requirements for realism, speed, and practicality. We will discuss how to utilize containerized dependencies and Docker for testing, including both apps and services you own and those you don’t. We’ll also go over the challenges with scaling container-based application development (you can only run so many microservices locally before minikube melts your laptop). Finally, you’ll see how Telepresence can "intercept" or reroute traffic from a specified service in a remote K8s cluster to your local dev machine.

1. Testing Java Microservices Apps without Cooking
Your Laptop: Using Docker & Telepresence
Daniel Bryant
@danielbryantuk

2. @danielbryantuk
tl;dr
2
• The inner dev/test loop can be painful with microservices & Kubernetes
• The pain increases as the number of services within your system increase
• You have options with +/- : mocks, service virtualisation, remocal tools
• Telepresence enables remote-to-local “remocal” development
• Choose your dev/test approach wisely!

3. @danielbryantuk
3

4. Setting the Scene
4

5. @danielbryantuk
Inner and outer dev loops
5
Hat tip to Mitch Denny (now 404): https://mitchdenny.com/the-inner-loop/
http://jorgemoral.es/posts/2020_03_17-develop_apps…

6. @danielbryantuk
You are building microservices, right?
6

7. @danielbryantuk
SOA: There’s just more stu
ff
(and dependencies)
7

8. @danielbryantuk
So, let’s run everything locally…
8

9. @danielbryantuk
tl;dr
9
“My laptop only has 16GB
RAM and you’re asking it
to run Kubernetes and a
JVM and a database???”

10. @danielbryantuk
Okay, let’s run everything remotely…
10

11. @danielbryantuk
Inner and outer dev loops with K8s
can be the same
11
• Write code
• Build container
• Push to registry
• Deploy to cluster
• Test
And can be …. SLOW.

12. @danielbryantuk
Automation can help…
12

13. @danielbryantuk
tl;dr
13
But you want a really fast inner loop (no docker build/push) …

14. @danielbryantuk
tl;dr
14 And you want to use your own tools.

15. @danielbryantuk
tl;dr
15
And you want to avoid the “works on my machine”
production vs local dev debacle

16. Options and Tradeo
ff
s
16

17. @danielbryantuk
What are your options?
17
• Mocks
• Mockito, PowerMock(Ito), EasyMock, JMockit
• Service virtualisation
• TestContainers
• Hoverfly, WireMock
• Remocal tooling
• Telepresence
• Devspaces, Okteto

18. @danielbryantuk
Mocks
18
https://site.mockito.org/

19. @danielbryantuk
Mocks
19
• Good
• Idiomatic (familiar language constructs etc)
• Quick and cheap
• Can help build your mental model (TDD-like)
• Bad
• Implicit assumptions coded in (“the three realities conundrum”)
• Di
ff
icult to keep up to date and share/coordinate
• Needs a test runner

20. @danielbryantuk
Service virtualisation
20
https://livebook.manning.com/book/testing-java-microservices/chapter-9/47

21. @danielbryantuk
Service virtualisation
21
https://livebook.manning.com/book/testing-java-microservices/chapter-9/47

22. @danielbryantuk
TestContainers
22

23. @danielbryantuk
Service virtualisation
23
• Good
• More realistic than mocks (can be the “real thing”, albeit resource constrained)
• Enables (wire-level) deterministic test of failure scenarios
• Easy to use large(r) amounts of data
• Bad
• Slower than mocks to initialise
• Can be tricky to configure
• Challenging to keep up to date and share (unless you use dedicated tooling/SaaS)

24. @danielbryantuk
Remocal tooling
24

25. @danielbryantuk
Remocal tooling
25
• Good
• Enables testing against (and poking of) the real thing
• Data sets can be large scale (as resources can be scaled on remote cluster)
• No need to build mental model of dependency (both good and bad!)
• Bad
• Need a solid network connection
• Mutating remote shared state can be an issue
• Lack of language bindings

26. @danielbryantuk
26

27. @danielbryantuk
What is Telepresence
27
• “Fancy Kubernetes VPN for development”
• “kubectl port-forward on steroids”
• “kubectl proxy all-the-things”
• A network bridge between your laptop and the Kubernetes cluster

28. @danielbryantuk
Telepresence: Local-to-Remote bridge
28

29. @danielbryantuk
Telepresence: Local-to-Remote bridge
29
www.youtube.com/watch?v=W_a3aErN3NU

30. Demo Time!
30

31. @danielbryantuk
Telepresence: Local-to-Remote bridge
31
telepresence connect
• Open a tunnel to the remote cluster; exposes “in-cluster” services/network/DNS
telepresence intercept my-service —port 3000
• Re-routes (intercepts) tra
ff
ic to my-service in the remote cluster to my local machine
telepresence login & telepresence intercept
• Create preview URL to isolate and share results of the intercept

32. @danielbryantuk
Telepresence: Local-to-Remote bridge
$ telepresence intercept dataprocessingnodeservice --port 3000
32
Using deployment dataprocessingnodeservice
intercepted
State : ACTIVE
Destination : 127.0.0.1:3000
Intercepting: HTTP requests that match all of:
header("x-telepresence-intercept-id") ~= regexp ("76a1e848-1829-74x-1138-e3294c1e9119:dataprocessingnodeservice")
Preview URL : https://[random-subdomain].preview.edgestack.me
www.youtube.com/watch?v=W_a3aErN3NU

33. @danielbryantuk
Preview URLs, Personal Intercepts
33

34. Docker Desktop Extension for Telepresence
34
getambassador.io/testing-with-telepresence-and-docker

35. 35

36. Wrapping up
36

37. @danielbryantuk
What to use, when
37
Mocks Service virtualization Remocal
Unit tests ✅
Integration tests ✅ ✅
Component tests ✅ ✅ ✅
End-to-end tests ✅ ✅
Poking around an
existing API
✅
Building an API ✅ ✅

38. @danielbryantuk
Conclusion
38
• The inner dev/test loop can be painful with microservices & Kubernetes
• The pain increases as the number of services within your system increase
• You have options with +/- : mocks, service virtualisation, remocal tools
• Telepresence enables remote-to-local “remocal” development
• Choose your dev/test approach wisely!

39. @danielbryantuk
Thank you! Questions?
39
getambassador.io/products/telepresence
getambassador.io/testing-with-telepresence-and-docker
Easy Debugging of Spring Boot Microservices Running on
Kubernetes
AL Developer O
ff
ice Hours
db@datawire.io / @danielbryantuk