2.3.5. Automated Testing in CI/CD (Developer Focus)

First Principle: Integrating automated testing throughout the CI/CD pipeline provides rapid feedback to developers, catching application defects early and accelerating the delivery of high-quality code.

For developers, automated testing is a cornerstone of building robust applications in a CI/CD environment. It ensures that code changes don't introduce regressions and that new features function as expected, all without manual intervention.

• Unit Tests: (Test individual components or functions of your application code in isolation.) They are fast, provide immediate feedback, and are typically run as the very first step in a build stage (e.g., in AWS CodeBuild). Keep them isolated from AWS by mocking the SDK — e.g. moto or unittest.mock for boto3 — so no real API calls are made; sam local invoke runs the whole function locally in a Lambda-like container, which is handy for quick local checks, but pointing it at local service emulators tests the integration rather than the logic in isolation.
• Integration Tests: (Verify that different modules or services within your application (or external dependencies) work correctly together.) They ensure your application components interact as expected.
• Functional/Acceptance Tests: (Validate that the application meets specified requirements from a user's perspective.) They confirm that the application fulfills its business purpose. End-to-end (E2E) tests go furthest: they drive the deployed application through its UI (clicking buttons, filling in forms) exactly as a user would.
• API Testing: Specifically tests the functionality, reliability, performance, and security of your APIs (e.g., API Gateway endpoints with Lambda functions).
• Mocks & Service Virtualization: Replace a dependency you don't control (a costly or unreliable third-party API) with a mock server or stub, so even integration tests stay fast, free and deterministic while your own components still run together for real.
• Sample Events: For a Lambda handler, get realistic input payloads from the Lambda console's Test tab event templates (for example, S3 Put) or from sam local generate-event s3 put, then feed them to sam local invoke.

Integrating Tests into CI/CD Pipelines:

• Tests are defined in your application's source code and executed as part of the build process (AWS CodeBuild).
• AWS CodePipeline can orchestrate dedicated test stages (e.g., deploying to a test environment and running automated tests before proceeding to production).
• Benefits: Early defect detection, improved code quality, faster feedback, increased confidence in deployments. A readable test suite also serves as executable documentation of how the system is meant to behave.

Scenario: You've made a code change to your application. Before deploying it, you want to automatically verify that individual functions work correctly, that different microservices can communicate, and that the application meets its business requirements.

⚠️ Exam Trap: Unit tests run in CodeBuild (during the build stage), not in CodeDeploy. Integration tests typically run in a separate CodeBuild action after deployment to a staging environment.

Additional Developer Tools on the DVA-C02

Several AWS developer tools appear on the exam at an awareness level — you won't need deep implementation knowledge, but you need to know what each does and when to use it:

AWS AppConfig (part of Systems Manager) manages application configuration and feature flags separately from code deployments. Unlike environment variables that require redeployment to change, AppConfig lets you update configuration in real-time with validation, gradual rollout, and automatic rollback if a configuration change causes errors. Use case: 'Enable a feature for 10% of users without redeploying' → AppConfig. Parameter Store can hold the same values, but only AppConfig adds validation, gradual deployment and automatic rollback. Code reads configuration through the AppConfig Data API: call StartConfigurationSession once, then poll GetLatestConfiguration with the returned token. (The older GetConfiguration API is deprecated.)

AWS CodeArtifact is a fully managed artifact repository compatible with npm, pip, Maven, and NuGet. It sits between your package manager and public registries, caching approved packages and blocking unapproved ones. Use case: 'Ensure builds only use approved package versions' → CodeArtifact. To pull from it in CodeBuild, give the service role codeartifact:GetAuthorizationToken, codeartifact:GetRepositoryEndpoint, codeartifact:ReadFromRepository and sts:GetServiceBearerToken, then run aws codeartifact login in the pre_build phase to fetch a token and configure the package manager. Tokens are temporary (12 hours by default), so never hardcode one.

AWS Copilot simplifies deploying containerized applications to ECS and Fargate. Instead of configuring ECS task definitions, services, load balancers, and VPCs individually, you run copilot init and Copilot provisions the entire stack. Use case: 'Fastest way to deploy a container to production' → Copilot (for ECS) or sam deploy (for Lambda). Note that AWS ended support for the Copilot CLI on 12 June 2026 and recommends Amazon ECS Express Mode or CDK L3 constructs for new work. It can still appear on the exam as the opinionated container CLI.

AWS CloudShell is a browser-based shell with the AWS CLI pre-installed and pre-authenticated with your console credentials. No local setup required.

Amazon Athena queries data in S3 using standard SQL — no infrastructure to manage. Use case: 'Analyze CloudFront access logs or S3 access logs without setting up a database' → Athena.

Amazon MemoryDB for Redis is a Redis-compatible, durable in-memory database. Unlike ElastiCache Redis (which is a cache that can lose data), MemoryDB provides durability with multi-AZ transaction logs. Use case: 'Redis-compatible database with durability guarantees' → MemoryDB.