Integration Testing and Mocking APIs for External Dependencies

This guide covers Skill 3.2.2 of the AWS Certified Developer - Associate (DVA-C02) exam. It focuses on how to validate interactions between application components and how to use AWS services to simulate external dependencies during development.

Learning Objectives

By the end of this module, you should be able to:

Differentiate between unit tests and integration tests in a cloud-native context.
Configure API Gateway Mock Integrations to simulate backend responses.
Understand the role of Integration Requests and Integration Responses.
Implement strategies for handling third-party service dependencies using retry logic and circuit breakers.
Use AWS SAM and development endpoints for local and staging tests.

Key Terms & Glossary

Integration Testing: Testing the combined functionality of two or more modules/services to ensure they work together (e.g., Lambda calling DynamoDB).
Mocking: Creating a simulated version of a service or API that mimics the behavior of the real component.
Endpoint: A specific URL where a service or API can be accessed for testing or production.
CORS (Cross-Origin Resource Sharing): A browser security feature that allows/restricts resources on a web page to be requested from another domain.
Proxy Integration: An API Gateway setting where the request is passed directly to the backend without modification.

The "Big Idea"

In distributed cloud architectures, applications rarely live in isolation. Integration testing is the "connective tissue" of your CI/CD pipeline. While unit tests prove your logic works, integration tests prove your infrastructure works. By using Mocking, developers can build and test front-end or service-to-service logic even when the actual backend or third-party API is unavailable, over-quota, or expensive to invoke.

Formula / Concept Box

Integration Type	Transformation Required?	Use Case
AWS_PROXY	No	Passing data directly to Lambda/other AWS services (Streamlined).
AWS (Custom)	Yes	Mapping specific request/response headers and bodies manually.
HTTP_PROXY	No	Passing data directly to an external HTTP endpoint.
Mock	N/A	Testing API Gateway responses without calling a backend.

Hierarchical Outline

I. Testing in Development Environments
- Local Testing: Using AWS SAM (Serverless Application Model) to invoke functions locally.
- Development Endpoints: Creating separate Stages (e.g., dev, test) in API Gateway.
II. API Gateway Mock Integrations
- Purpose: Test API structure and CORS without backend logic.
- Request Mapping: Defining the status code the mock should return.
- Response Mapping: Defining the JSON payload returned to the client.
III. Managing External Dependencies
- Resiliency Patterns: Implementing Retries with exponential backoff.
- Circuit Breakers: Preventing a failing dependency from crashing the whole system.
- Environment Variables: Using AWS AppConfig or Lambda variables to switch between mock and real endpoints.

Visual Anchors

API Gateway Mock Flow

Loading Diagram...

Service Integration Layers

\begin{tikzpicture}[node distance=2cm, every node/.style={rectangle, draw, minimum width=3cm, minimum height=1cm, align=center}] \node (UI) {Frontend / UI}; \node (API) [below of=UI] {API Gateway \ (Mocking Layer)}; \node (Lambda) [below left of=API, xshift=-1cm] {Lambda Function \ (Business Logic)}; \node (DB) [below of=Lambda] {DynamoDB \ (Data Store)}; \node (Ext) [below right of=API, xshift=1cm] {External API \ (Third Party)};

code

\draw[->, thick] (UI) -- (API);
\draw[->, dashed] (API) -- node[left] {Real} (Lambda);
\draw[->, dashed] (API) -- node[right] {Mocked} (Ext);
\draw[->, thick] (Lambda) -- (DB);

\end{tikzpicture}

Definition-Example Pairs

Mock Integration: A feature where API Gateway returns a response directly without calling a backend.
- Example: A frontend team needs to know the structure of a User object before the backend team has finished the database logic. The API returns a static JSON block { "id": 1, "name": "Test User" }.
Stage Variables: Name-value pairs that can be used in API Gateway to change configuration based on the deployment stage.
- Example: Setting an endpoint_url variable to mock-api.com in the dev stage and api.realcompany.com in prod.

Worked Examples

Setting up a Mock 200 OK Response

Create Resource: In API Gateway, create a /health resource.
Create Method: Choose GET and select Mock as the integration type.
Integration Request: Set a mapping template for application/json that returns {"statusCode": 200}.
Method Response: Add a 200 HTTP Status Code.
Integration Response: Map the 200 selection pattern to return the body {"status": "ok"}.
Test: Click "Test" in the console. You should see a successful 200 response without any Lambda attached.

Checkpoint Questions

Which integration type should you use if you want to pass a request to a legacy HTTP endpoint but need to rename several JSON fields in the request body?
- Answer: HTTP (Custom) Integration.
True or False: API Gateway Mock integrations incur the same costs as Lambda-backed integrations.
- Answer: False. While API Gateway still charges for the request, you save the cost of the Lambda execution and any downstream service calls.
What resiliency pattern should you implement when an external dependency is consistently timing out to prevent resource exhaustion in your own app?
- Answer: The Circuit Breaker pattern.

[!TIP] When testing event-driven applications, use Amazon EventBridge to replay events or inject mock events into your bus to see how your integration responds to specific payloads without triggering the real upstream source.

[!WARNING] Remember that Mocking only tests the interface (the contract). It does not validate the behavior of the external service. Always perform a final integration test with the real dependency in a staging environment before going to production.

DVA-C02 Study Guide: Integration Testing & API Mocking