Serverless Testing - AWS Lambda
Let's start with what is Serverless Framework?
- It manages your code as well as your infrastructure
- It supports multiple languages (Node.js, Python, Java, and more)
While the Serverless Architecture introduces a lot of simplicity when it comes to serving business logic, some of its characteristics present challenges for testing. They are:
- The Serverless Architecture is an integration of separate, distributed services, which must be tested both independently, and together.
- The Serverless Architecture is dependent on internet/cloud services, which are hard to emulate locally.
- The Serverless Architecture can feature event-driven, asynchronous workflows, which are hard to emulate entirely.
To get through these challenges, and to keep the test pyramid in mind, keep the following principles in mind:
- Write your business logic so that it is separate from your FaaS provider (e.g., AWS Lambda), to keep it provider-independent, reusable and more easily testable.
- When your business logic is written separately from the FaaS provider, you can write traditional Unit Tests to ensure it is working properly.
- Write Integration Tests to verify integrations with other services are working correctly.
- Acceptance – does the whole system work?
- Integration – does our code work against code we can’t change?
- Unit – do our objects do the right thing, are they easy to work with?
- A Lambda function is ultimately a piece of code that AWS invokes on your behalf when some input event occurs. To test that it integrates correctly with downstream systems you can invoke the function from your chosen test framework