Testing Serverless Applications in the Cloud
Your integration tests are failing again, not because your code is broken, but because a third-party sandbox is down. Sound familiar? In traditional applications, the testing pyramid emphasises unit tests: many fast unit tests, fewer integration tests, and even fewer end-to-end tests. This approach works well when most business logic lives inside the application code. Serverless systems are different. A good part of the configuration and application logic often lives directly in the cloud. Data transformations, event routing, permissions, and interactions between managed services are often handled by the cloud platform rather than the application code. Because of this, local tests alone cannot validate the full behaviour of a serverless system. For that reason, serverless architectures often require more integration testing directly in the cloud environment. Running tests against the cloud environment after deployment allows teams to validate not only application logic but also service integrations, infrastructure configuration, and event flows between cloud services.
Cloud providers offer local emulators such as LocalStack for AWS. These are extremely useful for development and rapid feedback loops. However, they do not always reproduce the exact behaviours of real cloud services. As a result, teams typically run integration tests both locally and directly in the cloud. In cases where serverless functions call external APIs, those integration tests become harder to run reliably.
External APIs Make Cloud Integration Tests Fragile
When serverless applications depend on external APIs, integration tests often fail for reasons completely outside your control. Third-party services may be unavailable, sandbox environments can contain limited or difficult-to-prepare test data, and in some environments outbound internet access may be restricted entirely. Even when APIs are available, keeping test data consistent across multiple systems can be challenging.
We ran into exactly these problems while building a serverless system that integrated with several external platforms, including Salesforce, financial systems, and government APIs. Some of our development environments had no outbound internet access at all, which meant those APIs could not be reached during testing. In other environments the APIs were technically available, but the sandbox environments exposed only limited test data, and preparing consistent datasets across multiple systems was difficult and time-consuming. As a result, integration tests became slow, fragile, difficult to trust, and were often skipped.
A common solution is to mock external APIs. Tools like WireMock allow teams to simulate external services using configurable request-response mappings. This approach works well when mock servers run as containers or standalone services. However, serverless platforms introduce new challenges. Functions can scale dynamically, instances can start and stop at any time, and in-memory state disappears when an instance is recycled. That means dynamically created mocks can disappear between test runs unless they are persisted.
These problems led me to build MockNest Serverless, a WireMock-compatible mock runtime designed specifically for serverless environments. It runs on AWS Lambda and persists mock definitions outside the runtime so they survive scaling events. If you are curious about the architecture behind this approach, I explain it in more detail in my AWS AIdeas article: MockNest Serverless - AI-powered API mocking for cloud-native testing.
If you are interested in how MockNest Serverless compares with other API mocking solutions, the project repository includes a detailed comparison table covering deployment models, protocol support (REST, SOAP, GraphQL-over-HTTP), and operating models.
Generating Mocks Faster with AI
Creating and maintaining mocks for complex APIs can be time-consuming. Modern APIs often expose dozens of endpoints, error scenarios and edge cases. Writing and keeping these mappings up to date manually delays features unnecessarily.
MockNest Serverless includes an AI-assisted mock generation feature to speed up this process. Mocks can be generated from an API specification combined with natural-language instructions, producing mock mappings automatically. Generated mappings are validated against the API specification and automatically refined if validation fails, ensuring valid results.
The demo below shows MockNest Serverless in Action, including the mock generation with AI.
This speeds up the creation of realistic test scenarios.
Getting Started with MockNest Serverless
MockNest Serverless runs entirely inside your AWS account and allows teams to simulate external APIs in environments where real services are unavailable, unstable, or difficult to control.
If you would like to try it, the project repository contains documentation, examples, and deployment instructions, including one-click installation from the AWS Serverless Application Repository. For the full story on how MockNest was built, such as architecture decisions, AI-assisted development with Kiro, and what is next, check out my AWS AIdeas article: MockNest Serverless - AI-powered API mocking for cloud-native testing. MockNest Serverless is open source and free to use, and contributions, feedback, and ideas are very welcome.
I am curious how others handle testing when serverless applications depend on external APIs. Please let me know in the comments.
Top comments (0)