DevFestVienna - Cloud Integration Testing Made easy with LocalStack and Testcontainers

Slide deck for the first 14.10.2023 Vienna DevFest.

Transcript

1. Cloud Integration Testing Made easy with LocalStack and Testcontainers Vienna 14.10.2023 localstack.cloud
2. Anca Ghenade - Developer Advocate - anca.ghenade@localstack.cloud @tinyg210
3. Testing…
4. Some things cannot just easily be tested, for example plane sensors. Landing gear sensors to be more precise.
6. So what’s the first thing we take away from this? Testing must be realistic.
7. But how realistic?
8. The truth is we’ve gotten very used to being “fake”. • Test data → a runner that cleans a 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.
9. Sometimes you have no choice.
10. WE INTERRUPT THE REGULAR SCHEDULED PRESENTATION TO BRING YOU THIS IMPORTANT STORY TIME
12. What about applications with dependencies in the cloud?
13. We want to keep it as real as possible when we’re testing our AWS-powered applications and the interaction between various components.
14. The reality:
15. Environment Setup: - AWS Account: Ensure you have access to an AWS account for testing purposes. - Separate Test Environment: Create a separate AWS environment for integration testing to avoid affecting your production environment. - Use of AWS Services: Set up the AWS services you need for testing (databases, storage buckets, queues, Lambda functions, etc). Test Data Preparation: - Data Generation: Prepare test data to use during your integration tests. This data should mimic real-world scenarios and cover different use cases. - Data Isolation: Isolate test data from production data to prevent accidental data loss or corruption.
16. Automate Integration Tests: - Write integration tests using test automation frameworks such as JUnit, TestNG, or a tool specific to your programming language or AWS services (e.g., AWS SDK for Java, AWS CDK). - Use testing libraries that support AWS services to interact with your resources programmatically (e.g., AWS SDKs, AWS Amplify, AWS CDK constructs). - Perform tests that exercise interactions between AWS services, such as Lambda functions invoking other services, S3 bucket operations, or SQS queue processing. Test Scenarios: - Test various scenarios, including both positive and negative cases. Ensure that your tests cover different service interactions, error handling, and edge cases.
17. Service Isolation: - Isolate AWS services as needed to ensure that your tests do not interfere with each other or the production environment. This can involve using separate AWS accounts or resource tagging. Testing AWS Lambda Functions: - Test AWS Lambda functions locally using a local development environment or tools like the AWS SAM CLI. - Automate the deployment and invocation of Lambda functions during testing.
18. Security Testing: - Include security testing in your integration tests to identify vulnerabilities and ensure that AWS security configurations are correct. - Test IAM roles, security groups, and network configurations. Cleanup and Resource Management: - Implement resource cleanup procedures to ensure that resources created during testing are properly disposed of to avoid unnecessary costs and resource leakage. Continuous Integration (CI): - Integrate integration tests into your CI/CD pipeline to ensure that tests are executed automatically whenever code changes are pushed.
19. Documentation and Reporting: - Document test scenarios, results, and any issues encountered during integration testing. - Use reporting and visualization tools to present test results in a clear and actionable format. Regression Testing: Periodically rerun integration tests to catch regressions as you make changes or updates to your AWS infrastructure and application code.
20. So things are kind of… complicated. 󰤆
21. What are some of the common approaches to testing with cloud dependencies?
22. The “let’s prove it works”
23. Focus on: • Mostly end-to-end and integration testing • Mocking only the necessities
24. Pros: • Confidence → Passing tests = it works • Fewer tests = less effort Cons: • Tests can’t provide many design cues • Slow feedback • High coverage is infeasible
26. The “mocking the boundaries”
27. Focus on: • Mock/fake remote systems • Mostly unit and end-to-end testing
28. Pros: • Every object is exercised by many tests → high regression value • Practical tests without deep knowledge of your mocks Cons: • One change and everything needs to be adjusted • End-to-end tests become redundant • Limited feedback/knowledge about interaction if you do TDD
30. Circling back to reality… reality is expensive, so we also want to test on a budget.
31. 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
32. And 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 Docker image, easy to install and start up • Support for 90-ish 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 ◦ redefining the way cloud apps are developed across the lifecycle!
37. I’ll show you some stuff
38. The “getting started with my app” example Source (Application): https://github.com/localstack-samples/sample-shipment-list-demo-lambda-dynamod b-s3 Source (Testcontainers): https://github.com/tinyg210/testcontainers-shipment-list-demo
40. Your application runs locally.
41. Scenario 1 Scenario 2
42. It all boils down to this:
44. Configuring your container *Resources are created programmatically in the @BeforeAll method
45. 1/2
46. 2/2
48. The “my apps is pretty much ready” example Source: https://github.com/tinyg210/stack-bytes-apigw-lambda-s3 Folder: github-actions-testcontainers
49. Test successful POST Test successful GET Test fails validation on incorrect values Test 404 on wrong param
52. Your application is deployed on LocalStack.
53. Tips and Tricks
54. Use init hooks to create your AWS resources.
57. Use a waiter to make sure your Lambdas are in state ACTIVE and not just created.
58. Source: https://aws.amazon.com/blogs/compute/coming-soon-expansion-of-aws-lambda-states-to-all-functions/
60. Use this nifty configuration to scan the LocalStack logs and make sure your instance is in the right state before the tests are allowed to start:
63. Streaming container output to an SLF4J logger
65. Lastly, here’s a workaround to shut down your Lambda containers
68. “Your application won’t even know the difference”
70. In the end…
71. testing I have no doubt that you would be bored senseless by therapy, the same way I'm bored when I brush my teeth and wipe my ass. Because the thing about repairing, maintaining, and cleaning is it's not an adventure. There's no way to do it so wrong you might die. It's just work. And the bottom line is, some people are okay going to work, and some people, well, some people would rather die.
72. Thank You!
73. Questions…
74. …for you
75. Just FYI - Top 3 podium - Game of correctness and agility - You can play as many times as you want
76. Answers
79. How much of your system you can test Cloud emulation Staging environments Real AWS Mocking 3 4 Service emulation 2 1