← Community

Verify the baseline

Prove the suite is green and the project is in a known state before and after a change — if it is already red, stop. Use when starting work, after a slice, before a refactor, or when asked to check that nothing broke.

---
name: verify-the-baseline
category: coding
description: >-
  Prove the suite is green and the project is in a known state before and
  after a change — if it is already red, stop. Use when starting work, after
  a slice, before a refactor, or when asked to check that nothing broke.
---

# Verify the Baseline

A change on top of a red suite is uninterpretable. You cannot tell your
breakage from the failure that was already there, you cannot bisect, and you
cannot tell a reviewer that you left the place better than you found it.
The first move is always the same: run what is supposed to be green, and
read the result.

This is not "run the tests at the end." It is the gate at both ends of the
work. Before, so you know the floor. After, so you know you did not drop
through it.

## Before you touch anything

Run the actual command the project uses. Not a subset you remember. Not the
file you are about to edit. The suite, the structural checks, the examples
the repo treats as canonical.

Record three things:

- **The command.** Exact. `pytest -q` is not `npm test`. The next person —
  including you after lunch — needs to re-run the same thing.
- **The count.** "7 unit examples pass. Both spec files validate." A vibe
  of green is how a skipped file becomes a surprise.
- **The time.** If this takes four minutes, say so. A baseline you will not
  re-run is not a baseline.

If anything is red, **stop.** You do not start a slice, a refactor, or a
cleanup on a red floor. Either:

- The environment is wrong (dependencies, flags, the wrong directory). Fix
  that, re-run, get green.
- The suite is actually broken on this branch. That is the work. Name it.
  Do not pile a feature on top.

The usual cheat is "those two were already failing." They are now your
failures. You touched the repo; you own the signal.

Shared publicly by the author and open for any use. See the Terms.