*This was a question asked by a student in the first run of the Serverless Testing Workshop, and I didn't have a great answer.* The example here is when you're testing a subsystem whose end point is delivering a message to a queue or event bus. What about systems downstream from there that are consuming these events? We don't need or want them to actually consume these. ## Potential solutions Strategies for dealing with this could be: - Ensure messages contain metadata identifying them as test data and that they're not to be consumed. - Have an isolated target environment that only includes parts of the system that will be tested where side effects won't be an issue as they will be disabled - Related: have the target environment be transient, and torn down as soon as tests complete. #TODO add more strategies and list out the pros and cons of the above. ## Concrete examples ### Syncing data from DynamoDB to Algolia Consider an application that uses a [[DynamoDB streams|DynamoDB stream]] to sync changes to a DDB table into an [[Algolia]] index via a Lambda function `syncToAlgolia` triggered from the stream. The issue here is that many of the integration and E2E test cases will require writing items to DDB, but only a small subset of these will likely require the Algolia integration to be fired. Given that Algolia charges for each write, these costs could quickly add up. We have a few options here: #### Option 1: Disable stream integration in automated test environment Disable the stream to Lambda integration completely in the test environment. If certain test cases need this to fire (e.g. the test cases for the `syncToAlgolia` Lambda function itself), then they can invoke the Lambda function directly as part of their test setup. Pros: - Easy to configure— just one boolean `enabled` per environment - Keeps logic simpler inside Lambda function - Faster test runs as Lambda invoked directly without latency of going via stream Cons: - Any manual user testing performed in this environment won't see data sync'd to Algolia. - Lower coverage: doesn't test that stream integration is set up correctly. This could be mitigated by adding a small [[Smoke testing|Smoke test]] to run post-deployment in production and manual user-testing environments that writes an item to DDB and verifies that it's synced to Algolia. #### Option 2: Make sync configurable and overridable by individual tests Add an environment variable `AUTO_SYNC_TO_ALGOLIA` (set to false for automated test environment but true for production) which the the `syncToAlgolia` Lambda function will read. Also allow a `forceSearchSync` flag to be added to individual DynamoDB items which are created by each test, so that each test has control over whether or not they need the data synced to Algolia. Pros: - Higher confidence given that test covers the stream configuration Cons: - Need to add conditional logic to Lambda - Extra data field on DynamoDB items is messy as it means that this field needs to be filtered out of any queries that return data to the user - If injecting this `forceSearchSync` flag through E2E tests, you may require it being passed in an API request. This could require it being added to a GraphQL schema.