> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Types of Automated Test in a CICD Pipeline > Overview of automated test types, where they run in CI/CD pipelines, and best practices for ensuring code quality, security, performance, and reliable production monitoring Welcome back, future [Fundamentals of DevOps](https://learn.kodekloud.com/user/courses/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 | Test Type | What it does | Typical tools / examples | | - | - | - | | Static analysis (SAST) | Analyzes source code without executing it to find style issues, coding errors, and some vulnerabilities | Linters (ESLint, pylint), SAST scanners (Semgrep, SonarQube) | | Unit tests | Verifies individual functions or components in isolation using mocks/stubs | xUnit, JUnit, pytest, Jest | | Integration tests | Verifies that multiple components or services interact correctly | Contract tests, API integration tests with real/stubbed services | | UI / UX tests (E2E) | Validates user flows and interface behavior | Selenium, Cypress, Playwright | | Acceptance tests (UAT / E2E acceptance) | Validates the system meets business requirements and is acceptable to stakeholders | Cucumber, Robot Framework | | Performance & load testing | Measures throughput, latency, and resource usage under load | JMeter, k6, Gatling | | Dynamic analysis (DAST / IAST) | Tests running application for runtime vulnerabilities or insecure behaviors | OWASP ZAP, Burp Suite, IAST agents | | Monitoring & production checks | Smoke tests, canary checks, synthetic transactions and real-user monitoring to validate production behavior | Prometheus, Grafana, New Relic, synthetic monitors | ## 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 | Pipeline Stage | Typical tests executed | Purpose / notes | | - | - | - | | Local / Pre-commit / Developer machines | Linting, static analysis, unit tests | Fast feedback; catch obvious issues before pushing | | CI / Early pipeline | Unit tests, lightweight integration tests, SAST | Maintain speed while widening the safety net | | Mid-pipeline / Staging | Full integration tests, contract tests, API compatibility, E2E acceptance | High-fidelity validation against staging or service mocks | | Pre-production / Performance environments | Performance & load tests, long-running integration tests | Simulate production scale safely | | Production or Production-like | DAST (in safe mode), canary deployments, synthetic monitoring, real-user monitoring | Validate runtime behavior and catch issues only observable in production | 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. ## Links and references * [Kubernetes Documentation](https://kubernetes.io/docs/) * [OWASP ZAP](https://www.zaproxy.org/) — DAST tool * [Semgrep](https://semgrep.dev/) — fast source code analysis * [Selenium](https://www.selenium.dev/), [Cypress](https://www.cypress.io/), [Playwright](https://playwright.dev/) — browser automation for UI/E2E tests We’ll cover cloud-specific implementations and demo CI/CD pipelines (including AWS examples) in a future article. > **[Watch Video](https://learn.kodekloud.com/user/courses/aws-certified-devops-engineer-professional/module/199ecdf9-a58f-4c2d-b9c9-eac36de111cd/lesson/9edced95-06d3-48be-9a36-c0e7f594059c)** > **[Practice Lab](https://learn.kodekloud.com/user/courses/aws-certified-devops-engineer-professional/module/199ecdf9-a58f-4c2d-b9c9-eac36de111cd/lesson/1aced0a2-8e7b-485a-8da1-f98d6b021afa)** This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.