Learning · CI/CD

Testing in the pipeline

What to automate where — unit, contract, integration, and e2e without making CI a overnight job.

Pipelines encode quality. The wrong mix either ships bugs or trains people to skip checks.

A practical pyramid

  • Unit / component — fast, numerous, run on every PR
  • Contract tests — consumer/provider agreements for APIs and events
  • Integration — service + real dependencies in CI (Testcontainers, ephemeral envs)
  • End-to-end — few, critical journeys; not a mirror of every unit case

Push coverage down the pyramid. E2E that retests business logic already unit-tested is expensive noise.

Gate on signal, not theater

Required checks should catch regressions you care about. Optional or informational jobs can inform without blocking. If everything is required and flaky, nothing is.

Environments for tests

Prefer ephemeral preview or pipeline-scoped environments over a shared “QA box” that drifts. Shared mutable envs create heisenbugs and queueing.

Data and secrets in CI

Use synthetic fixtures. Never lean on production data copies without controls. Inject secrets via the CI system’s secret store — not plaintext in YAML.

Performance and security as stages

Load and security scans belong on a cadence or on release candidates when they cannot be cheap enough for every PR. Still automate them — manual PDF audits do not scale.

← CI/CD