Run your tests automatically on every change (CI)

How to fix

1. 1 Add a CI workflow (e.g. GitHub Actions) that runs the test suite on every push/PR.
2. 2 Block merges when the suite fails.

Fix it in your stack

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: 22 }
      - run: npm ci
      - run: npm test

test:
  image: node:22
  script:
    - npm ci
    - npm test

Common mistakes

• • Running the tests in CI but allowing merges when they fail, so the check is advice, not a gate.
• • Letting a flaky test stay red until everyone ignores the result.
• • Running only the build, not the tests, and counting that as tested.

How to verify

1. 1 Open a recent pull request and confirm the CI run with build and tests is attached to it.
2. 2 Confirm branch protection requires that run to pass before merging.
3. 3 Push a change with a failing test to a branch and confirm the merge is blocked.

Questions

Does a small team need CI?

Yes, and it is the cheapest point to start. With one or two developers nobody reviews every change, so an automatic test run on each push is the only check a change gets.

What should CI run first?

The build and the existing tests, as a required check before merging. Add linting and type checks once those are green, and keep the run fast enough that nobody skips it.

Why does my report list this step?

A website scan cannot see this from outside. The step appears when you answer No to the question a scan asks about automated tests (CI), and it leaves your plan once you answer Yes on a later scan.