Devnexus 2025 - Cloud Integration Testing Made Easy for Your Java Apps

Slides for the Devnexus 2025 presentation.
Resources:
https://github.com/tinyg210/sf-java-meetup-demo
https://github.com/tinyg210/terraform-testcontainers-shipment-list-demo
https://github.com/tinyg210/stack-bytes-apigw-lambda-s3

Transcript

1. Cloud Integration Testing Made Easy for Your Java Apps Atlanta March 5th 2025 localstack.cloud
2. Anca Ghenade - Developer Advocate - anca.ghenade@localstack.cloud @tinyg210
3. Testing…
4. Some things cannot just easily be tested…
5. I was gonna show you my research on landing gear sensors…
9. So what’s the first thing we take away from this? Integration testing is important.
10. And second: it must also be realistic.
11. But how realistic?
12. The truth is we’ve gotten very used to being “fake”. • Test data → a clean database on every test run. We get green tests with migration problems. • Selenium → a fake user, using a mouse and keyboard, over and over again. We assume it’s realistic. • Stamina → the runtime is always fresh for tests. What about subtle memory leaks? • Scaling → tests run against a single process web server. Reality: a multi-thread environment.
13. Sometimes you have no choice.
14. WE INTERRUPT THE REGULAR SCHEDULED PRESENTATION TO BRING YOU THIS IMPORTANT STORY TIME
15. So my inspirations for this talk were our Code Cop and Justin Searls and his SCNA 2012 talk: To Mock or Not To Mock.
17. How do we test applications with dependencies in the cloud?
18. We want to keep it as real as possible when we’re testing our AWS-powered applications and the interaction between various components.
19. The reality: (of using a real cloud environment)
20. Your painful checklist for everything to consider: • AWS Account: Ensure access to a test AWS account. • Separate Test Env: Use a dedicated AWS environment. • Data Isolation: Keep test data separate from production. • Service Isolation: Use separate accounts or tagging to avoid conflicts. • Cleanup: Ensure resources are cleaned up post-testing. • CI Integration: Run tests automatically in CI/CD pipelines. • IAM Permissions: Ensure test users/roles have the necessary permissions. • Logging & Monitoring: Enable CloudWatch logs and metrics for debugging test failures. • Secrets Management: Store and manage test credentials securely (e.g., AWS Secrets Manager, Parameter Store). • Cost Management: Track and limit test resource usage to avoid unexpected costs. • Test Parallelization: Ensure tests can run concurrently without conflicts. • State Management: Handle persistent vs. ephemeral resources carefully.
21. So things are kind of… complicated. 󰤆
22. When it comes to testing, here are some common practices that we’re all guilty of. (At one point in our lives)
23. The “let’s prove it works”
24. Focus: • You do some quick end-to-end and integration testing. • Mocking only the necessities.
26. The “mocking the boundaries”
27. Focus: • Mocking remote systems. • Mostly unit and end-to-end testing. • Reuse mocks and get tangled when anything changes.
29. Circling back to reality… reality is expensive, so we also want to test on a budget.
30. Sure mocks are cheap, but you might end up paying a little differently.
31. Mocking carries the risk of not getting updated and if we mock everything, aren’t we just making sure that the mocks work as expected?
32. How can we bring the ease and speed of unit tests into our integration tests?
33. What is LocalStack and how can it help you? A fully functional local cloud stack that was born out of these exact concerns.
34. • Enables a highly efficient dev & test loop for cloud apps • Ships as a container image, easy to install and start up • Support for 100+ services (and growing): ◦ compute (Lambda, ECS, EKS) ◦ various databases (DynamoDB, RDS) ◦ messaging (SQS, Kinesis, MSK) ◦ some sophisticated/exotic APIs (Athena, Glue) • CI integrations & advanced collaboration features • Branching out into other areas: Chaos Engineering, IAM Security Testing, Cloud Ephemeral Environments, 3rd Party Extensions, etc
35. How much of your system you can test Cloud emulation Staging environments Real AWS Mocking So how much reality can we have in cloud application testing? 3 4 Service emulation 2 1
36. I’ll show you some stuff
38. Using Spring Profiles…
39. Scenario 1 (Production) Scenario 2 (Development)
40. Scenario 1 Scenario 2
41. Scenario 1 Scenario 2
42. What about those integration tests?
45. What approach do we use for testing our apps?
46. 1. The “my app changes frequently” example
47. Testing your application workflows
48. https://github.com/tinyg210/sf-java-meetup-demo
49. And your app runs against LocalStack.
50. 2. The “my app is pretty much ready” example Source: https://github.com/tinyg210/stack-bytes-apigw-lambda-s3 Folder: github-actions-testcontainers
51. Test successful POST Test successful GET Test fails validation on incorrect values Test 404 on wrong param
52. Your tests will revolve around an HTTP client
53. And your app runs inside LocalStack.
54. Tips and Tricks Dump
55. There are several ways to provision your infrastructure for testing.
56. 1. You do everything yourself. Programmatically with the AWS SDKs. (example: https://github.com/tinyg210/testcontainers-shipment-list-demo)
58. 2. Use init hooks to create your AWS resources.
59. a. AWS CLI scripts via init hooks (example: https://github.com/tinyg210/stack-bytes-apigw-lambda-s3)
61. b. Terraform configuration files via init hooks.
63. 3. Use LocalStack Cloud Pods
65. Locally…
66. There’s a catch: you need to use the same creation major version
67. Download on the fly… And see it in the webapp: https://app.localstack.cloud/pods
68. 4. Use a mix of all of the above. 󰤆 • spin up only desired services at startup • manage other resources via SDK clients
69. Now how do you interact with the container?
70. Did I mention the SDKs?
72. Or you can use AWS CLI commands.
74. What about testing in CI?
76. Your local tests…
77. In CI…
78. Some More Tips and Tricks
79. Use a waiter to make sure your Lambdas are in state ACTIVE and not just created.
80. Source: https://aws.amazon.com/blogs/compute/coming-soon-expansion-of-aws-lambda-states-to-all-functions/
82. Wait for LocalStack logs to tell you when to start, so that your instance is in the right state before the tests are allowed to start.
84. Streaming container output to an SLF4J logger.
86. Lastly, shutting down your Lambda containers finally work!
87. Before
88. This is just me debugging btw.
89. Thank you, Eddu, for that workaround! 󰚦 󰚦 󰗨
90. After
91. Make use of all the configuration flags: https://docs.localstack.cloud/references/ configuration/
92. Thank You!