# Testing Gates in CI/CD Pipelines: What to Automate and Where to Draw the Line > Learn how to design effective testing gates in CI/CD pipelines — which tests to automate, how to set coverage thresholds, and when manual gates still make sense. - **Published:** 2025-06-21 - **Author:** Clixo - **Reading time:** 6 min read - **Tags:** testing-gates, ci-cd, test-automation, quality - **Canonical URL:** https://clixo.sh/blog/testing-gates-in-ci-cd-pipelines-what-to-automate A CI/CD pipeline without testing gates is a conveyor belt — it moves code from one place to another without asking whether it should. Testing gates are the mechanism that gives a pipeline its quality guarantee: code does not advance to the next stage unless it has passed a defined set of checks. Getting this right requires knowing what to automate, how strict each gate should be, and when a human check still makes sense. ## What Testing Gates in CI/CD Pipelines Actually Are A gate is a condition that must pass before the pipeline proceeds. Gates are implemented as pipeline jobs that must return a success exit code. If a gate fails, the pipeline stops — the merge is blocked, the deploy does not happen, the artifact is not promoted. The power of gates is also their risk: a poorly calibrated gate that fails too often for the wrong reasons teaches the team to work around it. Gates require ongoing calibration to stay useful. ## The Four Gate Types Every Production Pipeline Needs ```mermaid flowchart LR PR["Pull Request"] --> G1["Gate 1\nStatic Analysis\nand Type Check"] G1 --> G2["Gate 2\nUnit and Integration Tests\nwith Coverage Threshold"] G2 --> G3["Gate 3\nDependency Security Scan"] G3 --> BUILD["Build and Deploy\nto Staging"] BUILD --> G4["Gate 4\nPost-Deploy\nSmoke Tests"] G4 --> PROD["Deploy to Production"] G1 & G2 & G3 & G4 --> BLOCK["Pipeline Blocked\non Failure"] ``` ### Gate 1: Static Analysis and Type Checking What it is: linting, type checking, and code style validation. These run in seconds and catch a meaningful percentage of errors before any test runs. How strict: Fail on any error. No warnings are acceptable in a gate — warnings that do not block become noise that the team learns to ignore. Where in the pipeline: First. This gate should fail in under 60 seconds so developers get immediate feedback without waiting for a full test run. ### Gate 2: Unit and Integration Tests with Coverage Threshold What it is: automated tests that verify application logic in isolation (unit tests) and against real service dependencies (integration tests). How strict: Set a minimum code coverage threshold and fail the pipeline if coverage drops below it. A reasonable starting threshold is 70-80% for most applications. Do not set the threshold higher than your current coverage — set it at current coverage and raise it over time. The coverage threshold is less important than which code is covered. Critical business logic — payment processing, authentication, data validation — should have near-complete coverage regardless of the overall threshold. Where in the pipeline: After static analysis, before build. ### Gate 3: Dependency Security Scan What it is: automated scanning of your dependency tree for known CVEs and security vulnerabilities. Tools like Snyk, `npm audit`, or Trivy handle this. How strict: Block on critical and high severity findings. Do not block on medium or low — the signal-to-noise ratio is too low, and blocking on medium findings means blocking on issues that have no realistic exploit path in your context. Where in the pipeline: Parallel with unit tests. This gate should not add to the critical path. ### Gate 4: Post-Deploy Smoke Tests What it is: a short suite of HTTP checks and synthetic transactions that run against the newly deployed environment to confirm the application is actually serving traffic correctly. How strict: Any failure triggers automatic rollback. A smoke test that passes despite a broken deploy is worse than no smoke test — it gives false confidence. Where in the pipeline: Immediately after each deployment stage (staging and production). ## The Coverage Threshold Calibration Problem Coverage thresholds are the most frequently misconfigured gate. Teams either set them too low (80% with critical paths uncovered) or too high (enforcing 95% across a large codebase causes constant friction and encourages gaming — adding meaningless tests to hit the number rather than writing meaningful tests). The better approach is to use path-based coverage requirements: - Set a reasonable minimum for overall coverage (70-75% for most codebases) - Set a higher minimum for specific directories that contain business-critical code - Fail if new code introduced in a PR has coverage below a threshold (differential coverage) Differential coverage gates are more useful than absolute coverage gates for growing codebases — they ensure new code is tested without requiring developers to retrofit tests for old code all at once. ## Where Manual Gates Still Belong Not every gate should be automated. Some checkpoints require human judgment. **Production approval gates:** For high-stakes releases, a required reviewer must explicitly approve before the pipeline continues to production. This is not a quality check — it is an organizational control. Many teams require this around major releases, peak traffic periods, or after significant architecture changes. **Release manager sign-off:** In regulated industries, certain deployments require documented approval from a named individual. This cannot be automated away and should not be. **QA exploratory testing:** Automated tests verify known behaviors. Exploratory testing catches the unknown unknowns — edge cases that no test anticipated. Reserve time for it in the release cycle. It does not belong in the automated pipeline, but it belongs in the process. ## Gates That Often Create More Problems Than They Solve **E2E test suites as mandatory gates on every PR.** End-to-end tests are inherently slower and flakier than unit or integration tests. Using them as a hard gate on every pull request creates bottlenecks. A better pattern: run E2E tests as a non-blocking check on PRs and a blocking check on the staging deploy. **Performance tests as PR gates.** Performance tests require production-equivalent data volume to be meaningful. Running them on every PR with synthetic data produces misleading results and wastes pipeline time. **Manual approval on every staging deploy.** Staging is for catching integration issues before production. Adding a manual approval to the staging deploy creates a human bottleneck on an environment that should be rapidly iterating. Reserve manual gates for production. --- Well-calibrated testing gates are how engineering teams ship with confidence at high frequency. The goal is not maximum coverage — it is maximum signal per unit of pipeline time, positioned to catch the right problems at the right stage. [Clixo designs CI/CD pipelines with testing gates calibrated to your team's risk tolerance and velocity goals — start the conversation](https://clixo.sh/#contact) --- Clixo · 1141 W Bryn Mawr Ave, Itasca, IL 60143, US · [hello@clixo.sh](mailto:hello@clixo.sh) [Start a build](https://clixo.sh/#contact) · [All services](https://clixo.sh/services) · [Agent guide (llms.txt)](https://clixo.sh/llms.txt)