You’re doing it wrong (tm). You setup and test lambda just like you test your controller action in an API.

Your handler should just accept the JSON value and the lambda context and then convert the JSON to whatever plain old object your code needs to do to process it and call your domain logic.

AWS has samples of what the JSON looks like for the different types of events. You can see the samples by just creating a new lambda in the console, click on test and then see the different types of events.

You can also log the JSON you receive and use that to setup your test harness. I don’t mean an official AAA type of unit test, it can be as simple as having a console app that calls your lambda function and passes in the JSON.

For instance in Python, you can wrapped your test harness in an

  if __name__ == "__main__":

block in the same file as your lambda.

This is the same method that a lot of people use to test API controllers without using something like Postman.

> Thing looked like an absolute nightmare to get up and running.

So you tried it? I don't remember it being hard to set up, at least compared to a DB. Or, you can use the underlying docker images (open source, https://github.com/lambci/lambci) to run your Lambdas in. SAM provides some nice abstractions, e.g. API gateway "emulation", posting JSON to the function(s), or providing an AWS SDK-compatible interface for invoking the functions via e.g. boto3. This way you can run the same integration tests you would run in prod against a local testing version.

seriously, its a function. if you remove the aws/lambda specifics you _should_ have something testable that you then call from your lambda handler.

That works for unit testing a specific component, but not so well for testing your system end-to-end.

The need for a staging instance for integration testing doesn't disappear when you run your API in lambda.

This! To me the only upside to the whole architecture (from a devs perspective) is that you can deploy these things to production independently of other parts of the system. If you can't do that with confidence because you're attempting to test it's functionality in some larger deployed context you've turned your monolith into a distributed monolith and now you have the worst of both worlds.

The good news; you should be able to accomplish most testing locally, in memory. The bad news; your test code is probably going to be much larger and your going to have to be very aware of the data model representing the interface to the lambda and you're going to have to test the different possible states of that data.

We created serverless-artillery[1] for testing end to end. As the bonus the load tests can then be used for acceptance and monitoring as well.

[1] https://github.com/Nordstrom/serverless-artillery

I've found unit testing to work fine for Lambdas. The biggest difference between running as a Lambda and running locally is the entry point. With a Lambda you have an event payload that (usually) needs to be parsed and evaluated.

I'll typically write all the core functionality first, test it, then write the lambda_handler function.

But how do you test lamba_handler then? Without a way to run lambdas locally, this sounds like a big black hole in your infrastructure.

You call it just like you call any other function. Your handler takes in either a JSON payload and a context object or a deserialized object depending on the language. You call it from a separate console app, your test harness etc.

Yup. You can log into the AWS console and generate an example test message. Copy that into your unit/integration test and bob's your uncle.

We deploy to a test stack and run a full integration test of the code running in AWS. I believe it's also possible to self-host locally, but we never really looked into it.