4 ms·

Do you have any resources on testing a Lambda? When I was fooling around with it, the only thing I ran into was that AWS Sam-client or whatever. Thing looked l

Do you have any resources on testing a Lambda? When I was fooling around with it, the only thing I ran into was that AWS Sam-client or whatever. Thing looked like an absolute nightmare to get up and running.

crtlaltdel 7y ago
seriously, its a function. if you remove the aws/lambda specifics you _should_ have something testable that you then call from your lambda handler.
- LargeWu 7y ago
  That works for unit testing a specific component, but not so well for testing your system end-to-end.
  - mypalmike 7y ago
    The need for a staging instance for integration testing doesn't disappear when you run your API in lambda.
- 0x445442 7y ago
  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.
mywittyname 7y ago
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.
- matthewbauer 7y ago
  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.
  - scarface74 7y ago
    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.
    - mywittyname 7y ago
      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.
  - bmm6o 7y ago
    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.
scarface74 7y ago
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.
erikerikson 7y ago
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 https://github.com/Nordstrom/serverless-artillery
guitarbill 7y ago
> 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 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.

crtlaltdel 7y ago

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

LargeWu 7y ago
That works for unit testing a specific component, but not so well for testing your system end-to-end.
- mypalmike 7y ago
  The need for a staging instance for integration testing doesn't disappear when you run your API in lambda.
0x445442 7y ago
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.

mywittyname 7y ago

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.

matthewbauer 7y ago
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.
- scarface74 7y ago
  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.
  - mywittyname 7y ago
    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.
- bmm6o 7y ago
  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.

scarface74 7y ago

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.

erikerikson 7y ago

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 https://github.com/Nordstrom/serverless-artillery

guitarbill 7y ago

> 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 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.