Study Guide: Testing Deployed Code and Environments in AWS

Testing in AWS is a multi-layered process that transitions from local unit testing to integration testing in the cloud. This guide focuses on verifying that deployed code functions correctly within the AWS ecosystem, using tools like API Gateway stages, Lambda aliases, and CI/CD pipelines.

Learning Objectives

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

• Create and execute application test events using JSON payloads.
• Manage isolated environments using API Gateway stages and Lambda aliases.
• Implement automated testing within an AWS CodeBuild project.
• Differentiate between deployment strategies like Blue/Green, Canary, and Rolling.
• Use Infrastructure as Code (IaC) to deploy and update test-ready environments.

Key Terms & Glossary

• AWS SAM (Serverless Application Model): An open-source framework for building serverless applications. It provides a shorthand syntax to express resources.
• Lambda Alias: A pointer to a specific Lambda function version, allowing you to abstract the version number from the caller (e.g., PROD pointing to version 5).
• API Gateway Stage: A logical reference to a lifecycle state of your API (e.g., dev, test, prod).
• Mocking: The process of simulating the behavior of external dependencies (like a database or 3rd party API) to test code in isolation.
• Canary Deployment: A strategy where a small percentage of traffic is shifted to a new version to test stability before a full rollout.

The "Big Idea"

In a cloud-native environment, "it works on my machine" is insufficient. Testing deployed code means verifying the integration between services. By using staging variables, environment aliases, and automated CI/CD gates, developers can ensure that code not only runs but also interacts correctly with IAM roles, VPCs, and other managed services before reaching production.

Formula / Concept Box

Hierarchical Outline

• I. Testing in Development Environments
  • Test Events: Using JSON payloads to simulate triggers (S3 events, API Gateway proxy requests).
  • AWS SAM Local: Invoking functions locally to simulate the AWS execution environment.
  • Mocking APIs: Using API Gateway to return hardcoded responses for testing frontend logic.
• II. Managing Isolated Environments
  • API Gateway Stages: Using Stage Variables to point to different backends (e.g., lambdaAlias = dev).
  • Lambda Aliases & Versions: Implementing Weighted Aliases to split traffic between two versions.
  • Infrastructure as Code (IaC): Using CloudFormation/SAM to recreate identical environments for UAT (User Acceptance Testing).
• III. Automating the Test Pipeline
  • AWS CodeBuild: Running unit and integration tests during the build phase.
  • Amazon Q Developer: Utilizing AI to generate unit test boilerplate and identify edge cases.
  • Rollbacks: Automatically triggering a rollback if CloudWatch Alarms fire during a deployment.

Visual Anchors

CI/CD Testing Workflow

This flowchart represents how testing is integrated into the automated release process.

API Gateway to Lambda Versioning

This diagram shows how Stage Variables allow a single API definition to point to multiple environments.

\begin{tikzpicture}[node distance=2cm, every node/.style={draw, rectangle, rounded corners, fill=blue!10, text centered, minimum width=3cm}]

% Nodes \node (api) [fill=orange!20] {\textbf{API Gateway}}; \node (dev_stage) [below left of=api, xshift=-1cm] {Stage: DEV\\texttt{var: alias=DEV}}; \node (prod_stage) [below right of=api, xshift=1cm] {Stage: PROD\\texttt{var: alias=PROD}}; \node (lambda) [below of=api, yshift=-2.5cm, fill=green!10] {\textbf{Lambda Function}}; \node (v1) [below left of=lambda] {Version 1 (Alias: DEV)}; \node (v2) [below right of=lambda] {Version 2 (Alias: PROD)};

% Arrows \draw[->, thick] (api) -- (dev_stage); \draw[->, thick] (api) -- (prod_stage); \draw[->, dashed] (dev_stage) -- (v1); \draw[->, dashed] (prod_stage) -- (v2);

\end{tikzpicture}

Definition-Example Pairs

• Integration Testing: Testing the communication between two or more AWS services.
  • Example: A Lambda function writes a record to DynamoDB, and the test verifies the record exists with the correct attributes.
• Staging Variables: Name-value pairs that can be used as configuration attributes in API Gateway.
  • Example: Setting a variable ${stageVariables.lambdaAlias} so that the dev stage calls the MyFunction:DEV alias while prod calls MyFunction:PROD.
• Test Payload: A JSON object that mimics the structure of an AWS event.
  • Example: A JSON file containing a "body" and "headers" key to simulate an HTTP POST request coming from API Gateway to a Lambda handler.

Worked Examples

1. Creating a Lambda Test Event via CLI

To test a deployed Lambda function named ProcessOrder with a specific JSON payload:

Explanation: This allows a developer to verify the function's logic and IAM permissions without needing the actual upstream trigger (like an SQS queue) to be active.

2. Weighted Aliases for Canary Testing

If you want to shift 10% of traffic to a new version (Version 2):

1. Create an alias named Live pointing to Version 1.
2. Update the alias to include Version 2 with a weight of 0.1.

Checkpoint Questions

1. What is the primary advantage of using Stage Variables in API Gateway when managing multiple environments?
2. Which AWS service is responsible for compiling source code and running automated tests during the CI/CD process?
3. How does a Canary deployment differ from a Blue/Green deployment in terms of resource usage?
4. What tool would you use to simulate an AWS environment locally on your laptop to test a SAM template?

[!TIP] Always use Amazon CloudWatch Alarms in conjunction with CodeDeploy. If the error rate spikes during a Canary deployment, CodeDeploy can automatically roll back to the previous version, preventing a widespread outage.