Prepopulate Lambda Console Testevents without dirty manual work using Terraform



You like Lambda testevents? Great! But with “automate everything”, manual console clicks are considered dirty! Keep your hand clean by automating the creation of Lambda test events. So you can give your team, and yourself prepopulated test events. This example shows you the terraform code - because this is the fastest way. With a little effort, you can translate it to CloudFormation or AWS-CDK!

New Lambda feature

The Lambda console has a new feature called “Shareable test events”. These “STE” allows you to share the Lambda test events defined in the console with other users in the same account. This feature is only accessible via the AWS console, so there is no automation at first glance…

Lack of automation

But as a fan of automation, you want to create your Lambda Resource with Infrastructure as Code, e.g. terraform or AWS-CDK V2.

Whats the documentation is not saying

The AWS documentation “Testing Lambda functions in the console” tells you that the shareable test events are stored as a schema in the Amazon EventBridge (CloudWatch Events) schema registry named lambda-testevent-schemas.

What the documenation does not tell you is how the shareable test events are stored.

That is relatively easy. When you have a Lambda function called “testee”, the events are stored as _testee-schema.

In terraform you can create these schema and the example events.

Define the Lambda function name as variable:

locals {
    lambda_function_name = "testee"
}

Create the aws_schemas_schema:

resource "aws_schemas_schema" "testee" {
name          = "_${local.lambda_function_name}-schema"
  registry_name = "lambda-testevent-schemas"
  type          = "OpenApi3"
  description   = "console tests test"

A complete IaC solution: main.tf

You may use the file from github.

This is the complete code:

locals {
    lambda_function_name = "testee"
}


resource "aws_schemas_schema" "testee" {
name          = "_${local.lambda_function_name}-schema"
  registry_name = "lambda-testevent-schemas"
  type          = "OpenApi3"
  description   = "console tests test"

  content = jsonencode(  {
  "openapi": "3.0.0",
  "info": {
    "version": "1.0.0",
    "title": "Event"
  },
  "paths": {},
  "components": {
    "schemas": {
      "Event": {
        "type": "object",
        "required": [
          "key1"
        ],
        "properties": {
          "key1": {
            "type": "string"
          }
        }
      }
    },
    "examples": {
      "Parameter1": {
        "value": {
          "key1": "value1"
        }
      },
      "Parameter2": {
        "value": {
          "key1": "value2"
        }
      }
    }
  }
} )
}

Part 1: Schema Definition

In the first part:

"Event": {
        "type": "object",
        "required": [
          "key1"
        ],
        "properties": {
          "key1": {
            "type": "string"
          }
        }
      }
    },

The schema is defined, so we only got one attribute, named “key1” with the type “string”. This definition is a little bit tricky.

But there is a workaround to create the schema: When you define a shared test event in the Lambda console and save this event, AWS will create the definition in the EventBridge registry for you.

Part 2: Sample events

"examples": {
    "Parameter1": {
    "value": {
        "key1": "value1"
    }
},

With the defined schema, you create examples with the matching values, so key1 must be present to fulfill the defined schema.

The test events are called Parameter1 and Parameter2. These are the names which the Lambda console will show.

How to pre-populate

So we need only a few things to pre-populate the shareable test events:

  1. A Lambda function
  2. An event scheme in the lambda-testevent-schemas schema registry
  3. Example events

Walkthrough overview

  1. Create lambda or us existing
  2. Update content in main.tf
  3. Call terraform apply
  4. Use it

Step 1 - Create Lambda

Author any lambda function from scratch:

You will see no shareable test events in the new created function.

Event registry

Also there is no schema in the event registry. You reach the registry:

  • Go to EventBridge
  • Choose Schemas
  • See the schemas , none at the moment

Step 2 - Update content in main.tf: Set Lambda name

1 locals {
2     lambda_function_name = "testee"
3 }

Step 3 - Call terraform apply

If you not have done so, first do terraform init

terraform apply

Your output should look like this at start:

Terraform will perform the following actions:

  # aws_schemas_schema.testee will be created
  + resource "aws_schemas_schema" "testee" {...

And like this when its finished.

aws_schemas_schema.testee: Creating...
aws_schemas_schema.testee: Creation complete after 0s [id=_testee-schema/lambda-testevent-schemas]

Notice, that this task took under one second.

See udpdated schema in EventBridge

Now the new testevents are created as _testee-schema .

See testevent

And you Lambda function got the events too:

  • Go to Lambda service
  • Choose “Edit saved event” in the Test section
  • See the different events
  • See the content of the event

See json in main.tf

33     "examples": {
34       "Parameter1": {
35         "value": {
36           "key1": "value1"
37         }
38       },
39       "Parameter2": {
40         "value": {
41           "key1": "value2"
42         }
43       }
44     }

Add testevents

Now you can add more test-events in the main.tf file and do terraform apply again.

 33     "examples": {
 34       "Parameter1": {
 35         "value": {
 36           "key1": "value1"
 37         }
 38       },
 39       "Parameter2": {
 40         "value": {
 41           "key1": "value2"
 42         }
 43       },
 44       "Parameter3": {
 45         "value": {
 46           "key1": "value3"
 47         }
 48       }
 49     }

The Parameter3 will show in the Lambda console at once.

Conclusion

It is easy to pre-populate Lambda test events. What do you think - does this support your development workflow? Or do you prefer local testing?

For more AWS development stuff, follow me on twitter @megaproaktiv

See also

Testing Lambda functions in the console

Similar Posts You Might Enjoy

Stop LLM/GenAI hallucination fast: Serverless Kendra RAG with GO

RAG is a way to approach the “hallucination” problem with LLM: A contextual reference increases the accuracy of the answers. Do you want to use RAG (Retrieval Augmented Generation) in production? The Python langchain library may be too slow for your production services. So what about serverless RAG in fast GO Lambda? - by Gernot Glawe

Custom runtime on Amazon Linux 2 - GO outperforms Node (3x) and Python (2x) with AWS Lambda Cold-start time

Lambda GO runtime is deprecated until the end of 2023. The new default custom Amazon Linux 2 runtime really speeds things up for GO. Now the cold-start is 2x faster than Python and 3x faster than node! - by Gernot Glawe

Querying Local Health Check URLs

Do you run software that provides locally available health checks via a webserver only reachable via localhost? In this blog post, I will show you an architecture that you can use to connect those local health checks to CloudWatch Logs and even receive alarms if things are not going to plan. - by Thomas Heinen