Use CloudFormation or Terraform infrastructure-as-code to provide "shareable" test events for realistic, not just local, testing of AWS Lambda functions...

I've never understood the appeal of "local development", that is, striving to imitate a cloud computing target on one's laptop. Often, there are resource-intensive utilities and proprietary, in-house tools to install. If my project involves a cloud-native paradigm like Lambda, I'm even supposed to integrate a tool that fakes interactions with AWS services and resources. That is extra work for the privilege of testing on my laptop without proving anything, because the cloud dependencies weren't real. ???

Given...

  • cheap, elastic cloud capacity (EC2 spot instances and the serverless variants of managed databases and caches are ideal for development),
  • fast connectivity (my home Internet service is cellular, in fact), and
  • multi-account AWS configurations and infrastructure-as-code templates (one or more isolated environments for each person),

...why not develop and test directly in the cloud?

To that end, I'm sharing IaC source for providing "shareable" test events to accompany Lambda functions.

Introduced in 2022, this mechanism for distributing sample events so that multiple people can test Lambda functions realistically, not locally, hasn't received much notice.

There's one wrinkle: conditional provisioning with retention. One "registry" serves all the Lambda functions in a given account and region. AWS creates it automatically the first time anyone creates a shareable test event for any Lambda function. If the registry isn't present, you have to create it in such a way that it won't be deleted when you de-provision your project's infrastructure. If it already exists, you should reference it without importing it to your project's IaC configuration.

Then, just register a "schema" named correctly for your Lambda function, choose names for your test events, and stash the JSON source.

With shareable test events, you and your colleagues can perform authentic tests in the Lambda service, instead of doing extra work to perform unrealistic tests on laptops.

Feature Announcement

aws.amazon.com/about-aws/whats-new/2022/03/aws-lambda-console-test-events

Sample Code

github.com/sqlxpert/stay-stopped-aws-rds-aurora/blob/b9c2457/stay_stopped_aws_rds_aurora.yaml#L883-L970

  • The resources are AWS::EventSchemas::Registry and AWS::EventSchemas::Schema in CloudFormation or aws_schemas_registry and aws_schemas_schema in Terraform.

  • As mentioned above, the lambda-testevent-schemas registry serves every Lambda function in an AWS account and region, so you've got to be able to create it conditionally, and it has to survive the deletion of your project. In CloudFormation, set DeletionPolicy and UpdateReplacePolicy to Retain . In Terraform, consider a removed block with destroy = false .

  • The required naming convention for schemas in this registry is _LambdaFunctionName-schema , where LambdaFunctionName is your function's name. The leading underscore and the trailing -schema are required.

  • In case it's not clear, each of your test events is a key in the examples object. The rest of the JSON blob stays the same.

  • For internal projects, your test events will be more specific than mine and won't require editing. Test execution can be automated but the idea of adding extra keys with instructions for human developers might be useful nevertheless.

In the comments on the LinkedIn version of this article, tell me what I'm missing by not doing local Lambda development...