In this tutorial, you’ll learn how to run local automated tests for AWS Lambda functions.
Make sure to read Designing Testable Lambda Functions for tricks on minimising the need to run local integration tests as well.
Configuring access to AWS Resources
- When a Lambda function is running on AWS, the code runs under a profile that is already authenticated, and authorisation is controlled by the IAM role assigned to your Lambda function.
- Although Node.js SDK requires you to initialise a region locally, it will already be initialised when running in AWS
Another critical thing to keep in mind, to avoid stupid mistakes and financial cost:
- If you’re working on a public repository (eg open-source code on github), never commit access keys to your version control system.
A good approach to authentication, that automates away a lot of potential problems, is to:
- create a separate AWS IAM account for testing, and assign the keys for that account to a separate profile in
- Configure IAM privileges for the test profile, so it can only access the test resources. Optionally, create an IAM role specifically for the profile, so you can add/remove privileges easily for various types of tests.
- In the test runner initialisation (so just once for the entire set of tests), tell AWS SDK to use the test profile, and pre-select the AWS region. For example:
Simulating Lambda events
You can just
fail depending on how you terminate the call execution.
Remember that the Context object contains properties that point to the currently executing function. A common trick for accessing non-AWS resources is to use those properties to detect the version and then load additional configuration files. If you have something similar in your function, remember to initialise the properties of the context object accordingly.
Simulating API Gateway requests
Important note: The content on this page is valid for Claudia API Builder 2.x. For 1.x versions, call the
router function and expect an API Builder Request Object
If you’re using
claudia-api-builder, require your API module and execute the
proxyRouter function. This is the entry-point Lambda execution, and has the same arguments as normal Lambda handlers (so
The event object
The event object coming into the handler function, during normal execution, is the API Gateway Proxy Object. In order to simulate the API builder routing, you’ll need to set the following properties:
requestContext.httpMethod: the HTTP method (eg
requestContext.resourcePath: the resource path (eg
You can fill in the other properties (eg
queryStringParameters) according to what the test expects, for example:
If you’re using generic path components, the path needs to be the generic definition, not the actual path, and the values should be in the
pathParams property. For example:
The mock Lambda context
The API Builder always terminates execution using the
done method, so you can provide only that one in your test mock context. This is a typical Node.js callback, so when it gets called, the first argument will be an
null, and the second argument will be the result in case there are no errors
Here’s a Jasmine example using API Builder: