Deployment
Testing Deployed Applications and Event Integrations
ImportantTest code at the unit, mocked-dependency, deployed endpoint, stack, and event-route boundaries in isolated development environments.
Aligned to AWS Certified Developer - Associate (DVA-C02) Version 2.1, verified August 23, 2026.
Why this matters
Local tests prove isolated code behavior; they do not prove that AWS permissions, stages, templates, event rules, and real service contracts are wired correctly. Good evidence comes from the narrowest test surface that exercises the risk.
Must Know
- Unit tests isolate application logic and mock external boundaries; deployed tests exercise configured roles, endpoints, integrations, and environment behavior.
- Integration tests verify contracts between components. Mock a third-party dependency when deterministic responses or failure cases are needed, but assert the request and response contract.
- Use a non-production API Gateway stage or development endpoint to test deployed changes without sending test traffic to production.
- Deploy AWS SAM or CloudFormation updates to the designated existing development or staging stack, then inspect outputs and service behavior.
- Event-driven tests must exercise producer event shape, route matching and non-matching, target invocation, retry or redrive, and the resulting side effect.
- Use representative data for valid, invalid, duplicate, timeout, and dependency-error paths; a manual invocation without assertions is not a repeatable test.
- Pin the artifact and configuration under test so a result can be reproduced.
Compare and Distinguish
- Unit vs integration vs deployed-endpoint test: isolated logic, component contract, and configured AWS behavior require progressively broader evidence.
- Mocked external dependency vs mocked application: mock the boundary you cannot or should not call; keep the application integration code under test.
- API stage vs custom domain: a stage is a deployment/configuration boundary; a custom domain is a client-facing hostname and mapping.
- Consumer-only event test vs end-to-end route test: directly invoking a consumer does not verify producer shape, rule matching, delivery, or redrive.
- Existing stack update vs unmanaged duplicate: update the declared test environment instead of creating console drift.
Scenario examples
- Scenario: Unit tests pass but deployed calls receive AccessDenied. Invoke the development endpoint and inspect the runtime role and integration evidence.
- Scenario: A third-party API is unavailable in automated development tests. Mock its documented contract and assert request, response, timeout, and error handling.
- Scenario: An EventBridge rule should route only approved event types. Publish matching and non-matching test events and assert target side effects.
- Scenario: A SAM change must be tested against current staging resources. Deploy the reviewed stack update to that environment and verify outputs and behavior.
Exam traps
- AWS-shaped JSON does not make a test an integration test if all dependencies remain mocked.
- A custom domain does not create or isolate an API deployment stage.
- Testing only the consumer skips the event route and permissions.
- Do not use production events or endpoints when an isolated development surface satisfies the requirement.
- A successful stack update does not prove application assertions or side effects.
- All-mocked tests cannot prove real IAM and managed-service integration.
Key takeaways
- Choose the smallest test boundary that still exercises the stated risk.
- Pin artifact and configuration so failures are reproducible.
- Use stages and existing declared stacks for isolated deployed testing.
- Test both matched and rejected event paths and their side effects.
- Make mocks faithful to the external contract and include failure behavior.
How it works
- The approved artifact and configuration are deployed to an isolated stage or stack.
- The test invokes a representative endpoint or publishes a representative event.
- Assertions verify response and durable side effects across the intended integration boundary.
- Logs, outputs, and failure paths identify which layer violated the expected contract.
When to use it
- Use unit tests for fast deterministic application-logic feedback.
- Use contract-faithful mocks for unavailable, costly, or failure-controlled external dependencies.
- Use deployed development endpoints when permissions and real AWS integrations matter.
- Use event-route tests when filter, delivery, target, and retry behavior matter.
- Use staging stack updates to evaluate reviewed IaC changes against an existing test environment.
Security and governance implications
- Use isolated test data and scoped test roles; do not copy production secrets into development.
- Sanitize captured requests, fixtures, snapshots, and logs.
- Restrict test-event publishing and stage deployment to intended environments.
- Confirm mocks do not accidentally fall through to production endpoints.
Failure signals and diagnosis
- When local passes and deployed fails, compare runtime principal, environment values, service endpoints, package, and network context.
- When an event test fails, inspect event schema, rule match, target permission, delivery attempt, and consumer output.
- When a stack test fails, read the failing resource event and service output instead of recreating resources manually.
- When a mock test gives false confidence, compare the mock contract with current provider behavior.
More detail
- Test behavior at the correct version and environment, not merely a similarly named branch.
- A mock must model response, timeout, and error behavior needed by the application contract.
- An event route has producer, schema, matching, permissions, target, and failure surfaces.
- Existing environment updates preserve the IaC source of truth and expose change effects.
Ready for the quiz?
- What can a deployed test reveal that a unit test cannot?
- Which code remains real when an external API is mocked?
- Why does a development stage differ from a custom domain?
- What parts of an event-driven route must an integration test exercise?
- How do you make a deployed defect reproducible?
Related objectives
- D3.2 — Test applications in development environments
- 3.2.1 — Test deployed code by using AWS services and tools
- 3.2.2 — Write integration tests and mock APIs for external dependencies
- 3.2.3 — Test applications by using development endpoints (for example, configuring stages in Amazon API Gateway)
- 3.2.4 — Deploy application stack updates to existing environments (for example, deploying an AWS SAM template to a different staging environment)
- 3.2.5 — Test event-driven applications