Running Tests on Every Push

You wrote tests, and they pass. But a test only protects you if it actually runs, and on your own machine it runs only when you or the agent remember to. One skipped run and a break slips through anyway. This chapter makes your whole suite run itself on every push, every time your code goes up to the shared repo, on a machine that is not yours.

7.5.1Tests only help if they runAdd note

The fix is continuous integration, or CI: a service that runs your whole test suite automatically, on every push, on a fresh machine that is not yours. The common one is GitHub Actions, and every major host has its own.

Because it runs from scratch in the cloud, it does not care what is installed on your laptop or whether the agent remembered to run anything. A green result there means green for everyone.

7.5.2Run them on every pushAdd note

You set this up with one small file in your repo. It installs your project on a clean machine and runs your tests every time you push:

# .github/workflows/ci.yml
name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm install
      - run: npm test

You do not memorize this, your agent writes it for your stack. What matters is the shape: on every push, a fresh machine checks out your code and runs your test command. Swap npm test for whatever your project uses.

7.5.3Block the merge on redAdd note

Running the tests is only half of it. The other half is refusing to merge when they fail. Turn on a branch protection rule that requires the CI check to pass, and a branch with a red suite simply cannot merge into main.

Now broken code is not a matter of discipline. The gate is mechanical: green merges, red waits until it is fixed.

Rule of thumb: a test suite that cannot block a merge is a suggestion, not a guardrail.

7.5.4Set it up once, it guards foreverAdd note

That one file is committed once and then guards every push forever, for you and for anyone who ever touches the project. You do not run it or remember it. It runs on its own, free, and turns red the instant something breaks.

This closes your safety net. A suite that runs itself and a gate that blocks red give you an app you can change without holding your breath, which is exactly what the next part is for: hardening and reshaping code you can prove still works. Later, the chapter on automating your deployment puts the deploy itself behind this same gate.

This prompt wires CI for your project:

Act as a senior engineer setting up CI for me.
Add a workflow that runs on every push and on
every pull request: install the project on a
clean machine and run my full test suite. Then
tell me the exact branch protection setting that
blocks a merge into main until that check is
green. Keep it minimal and explain each line the
first time.

My stack and test command:

Do this now: paste the prompt, commit the CI workflow your agent writes, then turn on the rule that blocks a merge until the suite is green.