Test Automation and Dev Environments

Master SAM local testing, Mock APIs, unit/integration tests, and API Gateway stages.

In the AWS DVA-C02 exam, testing questions mainly ask: 'How do you test your code locally before deploying it?' Since using actual AWS environments every time is costly and time-consuming, developers test locally first whenever possible. Let's walk through the key methods.

 

What is SAM Local Testing?

AWS SAM (Serverless Application Model) is a tool that makes it easy to build and deploy serverless applications like Lambda functions. By installing the SAM CLI, you can test Lambda functions on your own computer as if they were running in real AWS.

Think of it like a chef tasting food in the kitchen before serving it to guests — you verify everything works before going live.

Three commonly used SAM local commands:

sam local invoke

Runs a Lambda function directly on your local machine. You can pass a test event data file (in JSON format) along with it.

sam local start-api

Starts a local server that simulates API Gateway on your computer. You can send requests to a local address (e.g., http://localhost:3000) using a browser or Postman to test your APIs.

sam local generate-event

Automatically generates sample JSON data that mimics real events like an S3 file upload, an SQS message arriving, or an API Gateway request. This saves you from having to write test scenarios from scratch.

 

What are Test Events?

A Lambda function does not run on its own — it always needs something to trigger it (an event). For example, it might run when a file is uploaded to S3, or when a message arrives in an SQS queue.

When testing, you need to create these events yourself and pass them to the function. Each event source (S3, SQS, API Gateway, DynamoDB Streams, etc.) has its own unique JSON data structure.

You can create test events directly from the Lambda console, or use the sam local generate-event command described above.

 

Unit Tests vs Integration Tests

Unit Tests

You isolate a small piece of code (a single function or module) and test it on its own. External services like DynamoDB or S3 are replaced with Mock (fake) versions rather than real connections.

This is like removing just the engine from a car and testing it separately. Python developers commonly use the moto library, while Node.js developers use aws-sdk-mock.

Integration Tests

You test whether multiple services actually work together correctly. For example, verifying the full flow from Lambda to DynamoDB to S3 in a real environment.

 

API Gateway Stages

A Stage is a way to manage the same API across multiple environments — such as development (dev), staging, and production (prod). Think of it as running separate versions of the same app: one for developers, one for testing, and one for actual users.

Stage Variables: You can assign different Lambda function addresses or database endpoints to each stage. The code stays the same, but each environment uses its own configuration. Canary Releases: When deploying a new version, you send only a portion of traffic (e.g., 10%) to the new version first. If no problems appear, you gradually roll it out to everyone.

 

Amazon Q Developer

Amazon Q Developer is an AI-powered tool that assists with writing code. It supports automatic code generation, bug detection, and automatic creation of test code — like having an experienced developer colleague sitting next to you.

 

Exam Key Points

"Test Lambda locally" -- sam local invoke

"Simulate API Gateway locally" -- sam local start-api

"Generate sample event JSON" -- sam local generate-event

"Replace external services with fakes" -- Mock API (moto, aws-sdk-mock)

"Different settings per stage" -- API Gateway stage variables

"Send only partial traffic to new version" -- Canary release

"AI-powered code and test generation" -- Amazon Q Developer

Unit test = isolated, uses Mocks / Integration test = real service connections

Back to blog list