DVA-C03 Application Testing: SAM, CDK, Mocks, Test Events and Environments

Application testing in DVA-C03 Task 3.2 means proving that your code, your infrastructure templates and your environment wiring behave correctly before a change reaches users, using AWS tools that run tests quickly, locally where possible, and automatically on every change. The task has five skills, and this lesson follows them in order:

• Develop and validate tests with AWS SAM, AWS CDK and AWS CloudFormation: CDK assertion tests, template validation and linting, policy rules, and local and remote Lambda invocation.
• Mock external dependencies with AWS services: API Gateway mock integrations and the Step Functions TestState API with mocked results.
• Create test events: JSON payloads that match what Lambda really receives from API Gateway, Amazon SQS and Amazon EventBridge, and testing EventBridge event patterns.
• Create and configure environments: Lambda aliases, API Gateway stages and stage variables, container image tags and digests, and AWS Amplify branches.
• Use AI tools for testing: Kiro agent hooks that run tests, property-based tests derived from specs, and Kiro CLI in headless mode for CI.

The common thread is fidelity versus speed. A test that synthesizes a template in memory runs in seconds but cannot see IAM permissions; a test against a deployed stack is slow but real. Good pipelines use both, and many exam scenarios turn on a constraint such as "without deploying", "without invoking the function" or "with no backend code". Packaging artifacts belongs to Task 3.1, and deployment strategies, CodeDeploy and CodePipeline belong to Task 3.3.

You test infrastructure code by checking the synthesized template before anything is deployed: unit tests with the AWS CDK assertions module, schema checks with cfn-lint, and organisation policy checks with AWS CloudFormation Guard. Each tool answers a different question.

CDK assertion tests

The aws-cdk-lib/assertions module turns a stack into a Template object with Template.fromStack(stack). Synthesis happens in memory, so a Jest or pytest test runs in seconds with no AWS account and no deployment. Fine-grained assertions express the rules you actually care about:

• hasResourceProperties(type, props) passes when at least one resource of that type has the given properties.
• allResourcesProperties(type, props) passes only when every resource of that type has them.
• resourceCountIs(type, n) checks how many resources of a type exist.
• Match helpers (such as Match.objectLike and Match.arrayWith) allow partial matching.

const template = Template.fromStack(stack);
template.resourceCountIs('AWS::SNS::Topic', 3);
template.allResourcesProperties('AWS::SNS::Topic', {
  KmsMasterKeyId: Match.anyValue(),
});

This test fails if someone adds a fourth topic or creates any topic without a KMS key, and it runs in a unit-test step before cdk deploy.

Snapshot tests compare the whole template with a stored copy. They break on harmless changes such as asset hashes, CDK-injected metadata and other generated values after a CDK upgrade, so teams end up accepting new snapshots without reading them. Prefer fine-grained assertions for rules; keep snapshots, if at all, as a change detector.

Validating templates before deployment

The template validator, cfn-lint and CloudFormation Guard return a failing exit code when a check fails, so they fit a CodeBuild test stage that stops the pipeline.

The AWS SAM CLI runs the functions in your template inside Docker containers that emulate the Lambda runtime, so you can invoke them with realistic events on a laptop or a CI runner before deploying.

--env-vars env.json overrides environment variables for local runs; the file is keyed by each function's logical ID (or Parameters for all functions), so a local run can point at a dev table or a local stub.

What local testing cannot prove

A local invocation uses the credentials of your AWS profile, not the function's execution role. A function can therefore read and write a real DynamoDB table locally and then fail with AccessDeniedException once deployed, because SAM creates an execution role with only basic logging permissions when the function lists no Policies. Add the permissions the code needs (for example the DynamoDBCrudPolicy policy template scoped to the table). AWS notes that local testing does not validate permissions between cloud resources, which is why a good test plan also tests in the cloud.

You test a deployed function by invoking it in the cloud, from the Lambda console's Test tab or with sam remote invoke, and you share test payloads across a team with shareable test events.

• Private test events are saved on the function's Test tab and are visible only to the user who created them. They need no extra permissions.
• Shareable test events are visible to every user in the account who has the required permissions. Lambda stores them as schemas in an Amazon EventBridge schema registry named lambda-testevent-schemas, so users need EventBridge Schemas permissions (such as schemas:CreateRegistry, schemas:CreateSchema, schemas:DescribeSchema, schemas:UpdateSchema and schemas:ListSchemaVersions). A policy that allows only lambda:* lets a developer use private events but not create or see shareable ones.
• Console tests invoke the function synchronously and show the result, the log output and the duration.

The SAM CLI manages the same shareable events from the command line: sam remote test-event put, get, list and delete, identified by the stack name and the function's logical ID. sam remote invoke --test-event-name <name> runs a saved event against the deployed function, or --event-file runs a local file. Remote invocation tests the real execution role, networking and configuration that local runs cannot.

A test event must have exactly the structure the triggering service sends, or the test passes while production fails. The safest starting point is sam local generate-event or the console's event templates; the traps are listed below.

API Gateway proxy events

With a Lambda proxy integration, event['body'] is a string (or null), even when the client sent JSON. A hand-written event such as {"body": {"customerId": "c-42"}}, with the body as a nested object, hides the bug; the test event's body should be a JSON-encoded string, and the handler parses it with json.loads (or JSON.parse). Binary bodies arrive Base64-encoded with isBase64Encoded set to true.

A handler written and tested against 1.0 events fails with a missing-key error behind an HTTP API on 2.0. The fix is to generate fixtures with the matching template and read the 2.0 field locations (or set the integration to payload format 1.0).

Amazon SQS events

An SQS event source mapping invokes the function with a batch: {"Records": [...]}, where each record has messageId, receiptHandle, body, attributes, messageAttributes and more. The body is the message text exactly as sent, so a JSON message is a string to parse. Field names are lower camel case in the Lambda event (body, messageId), so copy a generated event rather than an SDK response when building fixtures.

Amazon EventBridge events

EventBridge delivers an envelope with version, id, detail-type, source, account, time, region, resources and the application data in detail.

You mock an HTTP dependency with an API Gateway REST API mock integration: API Gateway answers the request itself from mapping templates, with no backend code, so a frontend team or a test suite can work before the real service exists. HTTP APIs have no mock integration type; a stub there needs a real integration, such as a small Lambda function.

How a mock picks its response

1. The integration request mapping template outputs a status code, for example {"statusCode": 200}. Velocity (VTL) logic can branch on request data, for example emitting 503 when the query parameter mode is outage.
2. API Gateway matches that status code against each integration response's HTTP status regex. The integration response with no regex is the default and is used when nothing else matches.
3. The selected integration response maps to a method response with the same status and supplies the body from its own mapping template.

#if($input.params('mode') == 'outage')
{"statusCode": 503}
#else
{"statusCode": 200}
#end

Every status the mock returns therefore needs three parts: the request template that emits it, an integration response whose regex matches it (for 503, the regex 503) with a mapping template for the body, and a method response for that status. A status code that no regex matches is handled by the default integration response, so the client receives the default status and body rather than the error you meant to simulate. Gateway responses (such as DEFAULT_5XX) customise errors that API Gateway itself raises and do not take part in this selection.

You test one Step Functions state with the TestState API and an event pattern with the EventBridge TestEventPattern API; neither runs a workflow, delivers an event or invokes a target.

Step Functions TestState with mocks

TestState takes a single state's definition and an input, runs that state, and returns its output, status and next state, including the effect of InputPath, Parameters/Arguments, ResultSelector, ResultPath and OutputPath. You do not create a state machine or start an execution. Since November 2025 TestState accepts a mock for the state's service integration:

• A mocked result stands in for the integration's response, so the Lambda function or other service is never called.
• A mocked errorOutput (an error name and cause) lets you test Catch and Retry: the response reports status CAUGHT_ERROR, the nextState chosen and the catchIndex, which a test can assert on.
• With a mock, the roleArn parameter is optional, because nothing is invoked.
• Activity states, .sync and .waitForTaskToken integrations, and Map and Parallel states can be tested only with a mock; without one, TestState returns a validation exception, because it returns at once and cannot wait for a job or a callback.

The TRACE inspection level adds request and response detail for HTTP Task states only. ValidateStateMachineDefinition checks a definition's syntax but runs nothing.

EventBridge pattern testing

TestEventPattern (aws events test-event-pattern) takes an event pattern and a sample event and returns Result: true or false, which suits automated unit tests; the sample must include the required envelope fields id, account, source, time, region, resources (an empty array is fine) and detail-type, or the call fails validation. The EventBridge console's sandbox does the same interactively.

Patterns match only the fields they list, so they need neither detail-type nor every field of detail. The numeric operator compares only JSON numbers: a value sent as the string "250" never satisfies {"numeric": [">=", 100]}, and a one-sided comparison is valid.

Lambda aliases and API Gateway stages let one function and one API definition serve dev, test and prod: each environment calls a stable name that points at the code approved for it.

Lambda versions and aliases

• Publishing a version freezes the function's code and configuration, including environment variables. $LATEST is the only mutable version.
• An alias (for example invoices:live) is a named pointer to one version, with its own ARN. Integrations reference the alias, and promotion just moves the alias to the newly approved version, without changing any integration.
• Aliases carry no environment variables or other configuration. When two aliases point at one version, the code and its variables are identical for both, so per-environment behaviour has to come from outside the version: the function can derive its environment from the alias suffix of the invoked function ARN (context.invoked_function_arn ends in :live) and fetch that environment's settings from Parameter Store or AWS AppConfig.
• Resource-based permissions are scoped to the qualified ARN. Permission for API Gateway to invoke invoices:staging does not cover invoices:qa; add one per alias with aws lambda add-permission --qualifier <alias> and principal apigateway.amazonaws.com. A missing permission rejects the invocation before any code runs, so the function writes no logs and API Gateway returns an internal server error.

API Gateway stages and stage variables

A REST API stage (dev, test, prod) points at a deployment, a snapshot of the API definition. Editing a method changes the working definition, which the console's Test feature uses, but no stage serves the change until you create a deployment and associate it with that stage; deploying to dev leaves prod on its older snapshot. Auto-deploy exists only for HTTP API stages.

Stage variables are per-stage name-value pairs referenced as ${stageVariables.name} in integration URLs, Lambda function ARNs and mapping templates. One definition can send the dev stage to billing-dev.corp.internal and prod to billing.corp.internal, or invoke invoices:${stageVariables.fnAlias}.

Container environments are defined by which image each environment runs, and Amplify environments are defined by connected Git branches; both should make an environment run exactly what was tested.

Container image tags and digests

A mutable tag such as latest can be moved to a new image at any time, so a task started after the tests ran can run code that was never tested. Instead:

• Tag each build with a unique value, such as the commit SHA (payments:9e1d07b), and reference that tag in each environment's ECS task definition; promotion is an explicit task definition change.
• Turn on Amazon ECR tag immutability, so a pushed tag can never point to different content.
• When immutability cannot be turned on (for example a repository whose settings your team does not control), pin by digest: payments@sha256:<digest>. A digest is derived from the image content, so it cannot move. ECS resolves a tag to a digest for the tasks of one deployment, but a later deployment resolves the tag again.

Other ECR features, such as lifecycle policies and image scanning, manage storage and vulnerabilities (Task 3.1); only the reference in the task definition decides which image an environment runs.

AWS Amplify branch environments

• Each connected branch is its own environment with its own URL, for example main for production and develop for testing.
• Environment variables set at the app level apply to every branch; Add variable override gives one branch a different value, keeping one app and keeping settings out of the repository.
• Branch autodetection connects branches that match a pattern (such as feature/*) automatically, each with its own URL; autodetection access control can password-protect the auto-created branches.
• Pull request previews deploy each pull request to a temporary URL (and, for full-stack apps in private repositories, a temporary backend) and need the Amplify GitHub App for GitHub repositories. For public repositories, Amplify allows previews only for apps that need no IAM service role, because anyone who opens a pull request could otherwise run code with the app's permissions.

The official guide also names AWS Copilot environments, but the AWS Copilot CLI reached end of support on 12 June 2026, so do not choose it for new work; use task definitions, image tags, Lambda aliases, Amplify branches and API Gateway stages instead.

AWS's AI development tool Kiro can run tests automatically while its agent works, generate property-based tests from spec requirements, and analyse test results unattended in CI. Each feature has a specific trigger and limit.

Agent hooks for automated test execution

A Kiro agent hook pairs a trigger with an action. The action is either a shell command (such as pytest or npm test) or an agent prompt. A File Save trigger with a pattern such as lib/**/*.ts runs tests each time the agent saves or modifies matching files; File Create can scaffold a test file for each new source file; Post Task Execution runs after the agent completes a spec task. The other triggers are Prompt Submit, Agent Stop (when the agent finishes its turn), Pre Tool Use (which runs before a change exists), Post Tool Use, Pre Task Execution, File Delete and manual triggers.

File Create, File Save and File Delete triggers respond only to changes the agent makes; your own edits in the editor do not fire them. To test manual edits too, add a test watcher, a Git pre-commit hook or a CI build.

Property-based tests from specs

In the Kiro IDE, a spec's requirements written in EARS notation ("WHEN … THE system SHALL …") can be checked with property-based testing: Kiro extracts properties from the requirements, links each to its requirement and task, generates hundreds or thousands of random inputs and checks the code against every property. When a property fails, shrinking reduces the input to the smallest one that still fails, often a boundary value. You then fix whichever is wrong (the implementation, the test or the requirement), based on the intended behaviour. Passing properties are strong evidence, not proof, of correctness.

Kiro CLI in headless mode for CI

• Authentication uses an API key in the KIRO_API_KEY environment variable, stored as a CI secret (for example in AWS Secrets Manager, referenced from the buildspec).
• API keys require a paid plan, and on an administrator-managed subscription the administrator must first enable API key generation.
• kiro-cli chat --no-interactive runs one instruction without a session.
• --trust-tools approves only the tools listed (for example read-only file tools), while --trust-all-tools approves everything, including file edits and shell commands. Grant the narrowest list the job needs.

Typical CI uses are summarising a failing JUnit report, triaging regressions and suggesting missing tests for coverage gaps; the build's own test commands remain the source of pass or fail.