Skip to main content
Welcome back, future Fundamentals of DevOps students. This article explains the common automated test types used in a CI/CD pipeline, where they typically run, and what each verifies. Think of this as the quality-control flow for a food truck: from preparing ingredients to handing the finished meal to the customer, every stage needs checks.

​
Common Automated Test Types

​
Why these tests exist — the food-truck analogy

  • Static analysis = checking your recipe and instructions before anyone cooks.
  • Unit tests = tasting individual ingredients (is the bun fresh? is the patty cooked well?).
  • Integration tests = does the assembled burger actually work as a whole?
  • Acceptance tests = would customers buy it again? Does it match the menu/requirements?
  • UI tests = is the presentation and ordering experience correct?
  • Performance/load tests = can the truck serve a crowd during lunch rush?
  • Dynamic security tests = can someone exploit the running service?
  • Production monitoring = are customers actually getting what we promised?

​
Where these tests commonly run in a CI/CD pipeline

There is no one-size-fits-all pipeline. Choose which tests run where based on feedback speed, cost, and acceptable risk. Many teams follow a “shift-left” approach—catch what you can early and monitor in production for the rest.
Run heavy or destructive tests (e.g., full load tests, aggressive DAST scans) in controlled environments. Running these against production without adequate safeguards can cause outages or trigger false alarms.

​
Best practices and considerations

  • Fast vs. thorough:
    • Keep early checks (linting, unit tests) fast so developers get immediate feedback.
    • Reserve heavier tests (full E2E, load, deep DAST) for scheduled runs or pre-prod environments.
  • Shift-left where practical:
    • Catch syntax, style, and obvious security issues early with SAST and pre-commit hooks.
  • Isolation:
    • Unit tests should run in isolation (no network calls). Use mocks, stubs, and dependency injection.
  • Environment parity:
    • Integration and acceptance tests should run against environments that resemble production to reduce false positives/negatives.
  • Security testing strategy:
    • Combine SAST early in the pipeline with DAST/IAST for runtime detection of vulnerabilities.
  • Test flakiness:
    • Monitor flakey tests, track failures, and fix brittle tests—flaky tests erode trust in the pipeline.
  • Observability:
    • Add logs, metrics, and traces to tests and environments so failures are actionable.
  • Cost vs. value:
    • Prioritize tests that reduce the highest business risk per execution cost and time.

​
Quick summary

  • Start small and add more comprehensive checks as code moves through the pipeline.
  • Use static analysis and unit tests for fast, early feedback.
  • Use integration, acceptance, UI, and security testing for higher-fidelity validation in staging or pre-prod.
  • Reserve load, performance, and some DAST tests for environments that can safely emulate production or for controlled production validation.
  • Adapt placement of tests to your team’s risk tolerance, cost constraints, and desired feedback speed.
We’ll cover cloud-specific implementations and demo CI/CD pipelines (including AWS examples) in a future article.

Watch Video

Practice Lab