[Improvement]: Async EDA feedback from Heitor Lessa

[dancfox]

Contact Details

Dan Fox

Suggested Improvement

These are the recommendations from Heitor Lessa regarding the EDA pattern here.

• Separating Test resources from the actual app template — QA often don’t have access to change the original stack so they will get a access denied here in real life. You can pass by reference that S3 Destination bucket, and another template available within integ test would create/delete the stack making it ephemeral.

• Clean up test fixtures by having a service map of those resources - I typically recommend customers to use SSM to store a JSON of all resources that will be tested in Integ/E2E, so you don’t have to rely on CloudFormation stack outputs.. making it useful for any IaC framework, and you can use Parameters from Powertools to easily fetch and cache it in one-line

• README could make it clearer about the Listener Function being a separate entity - I only fully understood after I opened the template.yaml. What you’re doing is great, you’re making sure you can assert the side effect. You can strengthen the case by adding another diagram to explain that the Listener function is connected to the Destination bucket for completeness.

• Slight confusion between integration and E2E - Since you’re testing the side effect in a blackbox scenario, I’d consider this a E2E and not an Integ test. I’d use an Adapter to split tests: 1/ Can my code write to S3? 2/ Can my listener function write to DynamoDB?, then do an E2E test, so you can save E2E test execution ($, time) if these fail earlier.

• Add a note about testing IAM permissions - most customers find out too late in async testing that the middle part doesn’t have IAM permissions, and debugging that is a nightmare (with our tools)

• Switch to DynamoDB On-demand - you’re using a low provisioning which will always cost (it’s test I know!) … but for the scenario I asked (concurrent S3 Objects) this can turn tests flaky