Testing, quality gates and artefacts

The test pyramid

Tests differ in speed, cost and how much they cover. The test pyramid is a simple guide for the mix: a wide base of small, fast tests and a narrow top of big, slow ones.

Before any test runs, linting and static analysis read the code without running it. A linter (ESLint, Ruff, Checkstyle) catches style problems and simple bugs such as unused variables. Static analysis tools (SonarQube, Semgrep, CodeQL) find deeper problems, including some security bugs. They are the cheapest checks, so they run first.

Coverage: a signal, not a goal

Code coverage is the percentage of lines (or branches) that ran during the tests. Low coverage clearly shows untested code. But high coverage does not prove good tests: a test can run every line and check nothing. When a coverage number becomes a target, people write tests that chase the number. Use a sensible floor (for example, do not let coverage drop below the current level) and review what the tests actually assert.

Flaky tests

A flaky test sometimes passes and sometimes fails with no code change, often because of timing, shared test data or calls to real external services. Flaky tests teach the team to ignore red builds. Fix them quickly, or quarantine them: move them out of the blocking suite, with a ticket and an owner, so they do not block everyone while being fixed. Blindly re-running failed tests until they pass hides real bugs.

Quality gates

A quality gate is a set of rules a build must meet to continue: all tests pass, coverage at or above a threshold, zero lint errors, no critical vulnerabilities in dependencies or the image. If any rule fails, the pipeline stops and says why.

Artefacts

An artefact is the output of a build that you deploy or share: a container image, a .jar file, an npm package, a Python wheel, a zipped static site. Two rules matter. Versioned: every artefact has a unique version you can trace back to a commit. Immutable: once published, an artefact never changes; a fix means a new version.

Tagging images

Tag every image with the git commit SHA, so you always know exactly which code is running. For releases, add semantic version tags. Semantic versioning (semver) is MAJOR.MINOR.PATCH: bump MAJOR for breaking changes, MINOR for new features, PATCH for fixes. Teams often also push moving tags such as 1.4 and 1, which point to the newest 1.4.x and 1.x.y. Never deploy production by the latest tag: it changes under you. An image digest (sha256:...) is the fully immutable name of an image.

GIT_SHA=$(git rev-parse --short HEAD)          # for example 9f3c2ab
docker build -t registry.example.com/shop-api:sha-$GIT_SHA .
docker tag registry.example.com/shop-api:sha-$GIT_SHA registry.example.com/shop-api:1.4.2
docker push registry.example.com/shop-api:sha-$GIT_SHA
docker push registry.example.com/shop-api:1.4.2

Pipeline speed

• Cache dependencies keyed on the lock file hash, so unchanged dependencies are not downloaded again.
• Run independent jobs in parallel (lint, unit tests, image scan) and split big test suites across several runners.
• Use Docker layer caching: copy the lock file and install dependencies before copying the source code.
• Run only what changed in a large monorepo, using path filters.