2.1.2.1. Types of Automated Tests in DevOps

2.1.2.1. Types of Automated Tests in DevOps

A test suite that takes 45 minutes to run will be skipped by developers under deadline pressure. The testing pyramid exists to solve this: most tests should be fast, cheap, and granular, with progressively fewer tests at each level of integration.

Unit Tests (~70% of your tests) validate individual functions or methods in isolation, mocking external dependencies. They run in milliseconds and catch logic errors immediately. In CodeBuild, unit tests typically run in the build phase as part of mvn test or npm test.

Integration Tests (~20%) validate that components work together — API calls to real databases, service-to-service communication, IAM permission checks. These require a test environment and take seconds to minutes. Run these in a dedicated CodePipeline stage after the build succeeds.

End-to-End (E2E) Tests (~10%) simulate real user workflows across the full stack. They're slow (minutes), flaky (dependent on infrastructure), and expensive — but catch issues that unit and integration tests miss. Use Selenium, Cypress, or AWS Device Farm for browser-based E2E testing.

Security Tests scan for vulnerabilities in code (SAST) and running applications (DAST). Tools: Amazon CodeGuru Reviewer for code quality, Amazon Inspector for container/EC2 vulnerabilities, and third-party scanners like Snyk or Checkmarx integrated as CodeBuild build phases.

# buildspec.yml — test phase example
phases:
  build:
    commands:
      - npm run test:unit          # Fast, run every build
  post_build:
    commands:
      - npm run test:integration   # Slower, still run every build
      # E2E tests run in a separate pipeline stage, not here

Exam Trap: The exam may present a scenario where "all tests pass in staging but the app fails in production." This usually points to missing integration tests (staging uses mocked services) or environment configuration differences — not a unit test gap.