Unit Tests
Since a Lambda function is ultimately just a normal function, that Amazon would call on your behalf when some event fires. You can still invoke the function yourself by passing in a stubbed or mocked event and context objects.
Integration Tests
Integration tests exercise system’s Integration with it’s external dependencies.
The important thing to remember here is that, the purpose of these tests is to test the integration points with other systems, so when you’re running these integration tests the function should be configured to talk to the real downstream systems, that is, the real DynamoDB, not mocks or stubs, and not even simulated environments like DynamoDB local.
Acceptance Tests
Acceptance tests exercise system End-to-End from the outside. For these end-to-end tests you need to exercise the system from the outside, through its interfaces, which for API endpoints, it means exercising the system through HTTP.
The only difference between the two types of tests is in how our code is invoked, whether it’s invoked locally by our test runner, mocha or by API Gateway. So we can actually reuse the same test cases we created for the integration tests, and call the deployed API endpoints in the when step instead.
Running function locally
Using Serverless nodeJS framework
npm run sls -- invoke local
Using AWS SAM
sam local invoke
or
sam local start-api
Use these commands to test your serverless function code locally
Other Tools
Postman – API / Acceptance Testing
LocalStack – An easy-to-use test/mocking framework for Cloud applications