Building Software

Engineering Fundamentals for the Agent Era

Contents Section 2, Verification

Continuous Testing and Fast Feedback

Mistakes to catch in review

  1. A failing test marked as skipped so the pipeline turns green.

  2. Type-checker or linter warnings suppressed with ignore comments instead of fixed.

  3. A pipeline that runs only part of the suite, letting a broken integration merge.

  4. An agent that reports the suite green from its own sandbox, where a fixture file or an environment variable exists that CI does not have.

Running every check on every change so you know within minutes, and ideally seconds, when something breaks.

Topics

Continuous Integration Pipelines
Automatically building and testing every change, with results attached to the change itself.
Types, Linters and Static Analysis
Checks that run without executing the code, including secret and dependency scanners, and catch whole classes of mistakes cheaply.
Merge Gates
Blocking changes that fail their checks, and treating a broken main branch as an emergency.
Fast Feedback
Keeping the suite fast enough to run on every change through parallelism, test selection and watch modes.
Reproducible Environments
Pinned toolchains, containers and lockfiles so local and CI results agree.

You understand it when you can

  • Set up a pipeline that runs type checks, linting and tests on every push and blocks merging when any of them fail.
  • Explain what your suite proves when it is green, and what it cannot prove.
  • Cut a slow suite's feedback time by splitting, parallelizing or selecting tests, without dropping coverage.

Drill

An agent's pull request turns a red pipeline green by marking two tests as skipped, adding an ignore comment above a type error, and deleting the integration-test job from the CI configuration. Find each change that hides a failure, and state what the pipeline no longer proves.

Start here

Watch

Top 10 Rules For Continuous Integration

Dave Farley, 2020. 18-minute explainer.

States the working rules behind CI, including commit often, never leave the build broken, fix or revert a red main immediately and keep the build fast, which are exactly the rules skipped tests and deleted jobs break.

Watch

Tools for Continuous Integration at Google Scale

John Micco, 2012. 64-minute talk.

Describes how Google's TAP system uses the dependency graph to run only the tests affected by each change, the classic answer to keeping feedback fast without dropping coverage.

Read

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

Jez Humble and David Farley, 2010.

Introduced the deployment pipeline: every commit runs through staged automated checks, and a failure at any stage stops the change from going further.

Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations

Nicole Forsgren, Jez Humble and Gene Kim, 2018.

Presents the survey research linking test automation, trunk-based development and fast feedback to delivery performance, which is the evidence behind treating a slow or skipped suite as a real cost.

Continuous Delivery Pipelines: How to Build Better Software Faster

Dave Farley, 2021.

A short practical handbook on pipeline stages (commit tests, acceptance tests, version control of everything, infrastructure as code) and how to keep each stage fast and trusted.

Primary sources

  • Reference

    Continuous Integration (Martin Fowler)

    The canonical, recently revised description of CI practices: a self-testing build on every push, fixing broken builds immediately, keeping builds fast and testing in a clone of production.

  • Manual

    About protected branches (GitHub Docs)

    The official reference for required status checks and other branch rules that stop a pull request from merging until named CI jobs pass, which is the mechanical form of a merge gate.