When people first started using the term “serverless,” it created some confusion in the industry. Some people jokingly wondered how they could run apps without servers.
Well, the servers still exist, but their management and operation are handled on your behalf by the cloud provider.
Using serverless architecture enables organisations and engineers to focus on what’s important — building great, performant, and cost-effective applications that stand out in the market.
How Do You Test Serverless Architecture?
While serverless introduced a lot of simplicity into the process of building and shipping software, some challenges can come into play around testing.
First of all, testing locally is complex because serverless apps are dependent on cloud services. This is true for both unit and integration tests, where you need mocking and stubbing services to make sure that the application is working correctly.
Even though this might be a bit of additional work, it provides a better way to test in isolation, and your pipelines will start failing because of issues in your code, not the dependencies.
Second, integration tests are more diffiuclt and important as there are multiple services/components integrated together. This increases the risk of creating configuration/setup bugs in addtion to the potential existing code defects.
So what are we supposed to test? How do we test our app on both the unit and integration levels?
How can we make sure our app will work properly in a live environment, given that we’ve mocked other services while developing on our local?
And how can we test the interaction with the cloud services (AWS services in this case) without having to test the service itself?
This article aims to answer these questions to help you effectively test your serverless apps. So let’s get started.
What are we building?
AWS offers a set of serverless services (services that run in the cloud, on hardware and systems that we do not manage). This post will cover a few of them:
- Lambda (Cloud…