Automated Testing

Automated testing is the practice of running a suite of programmatic checks against an application — without human involvement — to verify that it behaves correctly after every change. In a CI/CD pipeline, automated tests are the mechanism that converts a green build into a deployable release. A build that compiles successfully but fails its tests is not ready for production. A build that passes every test is a verified candidate. The test suite is what gives the pipeline its confidence, and that confidence is what makes frequent, low-risk deployment possible.

Testing as a Pipeline Gate, Not an Afterthought

In teams without CI/CD, testing is often a phase — something that happens after development is done, usually performed by a dedicated QA team, usually close to a release deadline. The problem with this model is timing. A bug found the day after it was written takes minutes to fix. The same bug found three weeks later, after the developer has moved on to different work and the codebase has changed significantly, can take hours or days — and may require changes across multiple files to untangle.

CI/CD moves testing to the point of change. Every commit triggers the test suite. Every pull request must pass before it can be merged. The feedback loop collapses from weeks to minutes, and the cost of each bug collapses with it. The test stage is not a quality checkpoint at the end of the pipeline — it is a continuous quality signal running at every step of it.

The Test Pyramid — Balancing Speed, Coverage, and Cost

Not all tests are equal in cost or speed. The test pyramid is the mental model that guides how a healthy test suite is structured. It describes three layers of tests, each with a different scope, speed, and quantity. The pyramid shape is intentional — many fast, cheap tests at the base; fewer slow, expensive tests at the top.

Test Speed and Reliability in the Pipeline

A slow test suite is a pipeline that developers learn to ignore or work around. If every PR triggers a 45-minute test run, developers stop waiting for results, start merging speculatively, and lose the tight feedback loop that CI/CD is supposed to provide. Test suite speed is not a vanity metric — it is a direct measure of how useful the pipeline is in practice.

Flaky tests — tests that pass or fail intermittently without any change to the code — are the other major reliability threat. A flaky test erodes trust in the entire suite. When developers see a red pipeline, their first instinct should be "something broke" — not "probably just a flaky test, let me re-run it." Every flaky test that is tolerated trains the team to distrust the pipeline, and a distrusted pipeline is an ineffective one. Flaky tests must be fixed or quarantined immediately.

Code Coverage and Thresholds

Code coverage measures the percentage of the codebase that is exercised by the test suite — which lines, branches, and functions are touched during a test run. It is a useful signal, but it is not the same as quality. A codebase can have 100% coverage and still have terrible tests if the assertions are weak. Coverage tells you what the tests touch; it says nothing about whether those tests would catch a real bug.

Coverage thresholds in the pipeline — failing the build if coverage drops below a minimum — are a reasonable guard against regressions. A threshold of 80% does not mean the code is 80% correct; it means the team has agreed not to let untested code accumulate unchecked. Setting the threshold too high (99%+) incentivises writing tests for the sake of coverage rather than for correctness. Most teams find 70–85% a practical range for enforced pipeline thresholds.

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - run: npm ci                           # Clean install from lock file

      - run: npm test -- --coverage           # Run tests and collect coverage data
        env:
          CI: true                            # Many test runners behave differently in CI mode

      - name: Enforce coverage threshold
        run: npx jest --coverage --coverageThreshold='{"global":{"lines":80}}'
        # Pipeline fails if line coverage drops below 80%

      - uses: actions/upload-artifact@v4      # Store coverage report for review
        with:
          name: coverage-report
          path: coverage/

Practice Questions

Answer in your own words — then check against the expected answer.

Lesson Quiz