chore(makefile): derive the bats test count instead of hardcoding it

[LukasWodka]

The problem

make help advertised a "868-test bats suite". The real total on develop is 946, and nothing enforces the two agree — so the number drifts on every PR that adds a test, and had been wrong for a long time.

It also appeared a second time, in the check rationale comment ("the repo's real unit suite (868 tests)"), which the original report didn't mention. Both are fixed here; a grep confirms no hardcoded suite count remains in the repo.

The fix

Derived from the source of truth rather than written down:

BATS_TEST_COUNT = $(shell grep -h '^@test' scripts/tests/*.bats 2>/dev/null | wc -l | tr -d ' ')

bats declares one test per @test at line start, so this matches its own count exactly. Verified against a real run: 946 derived, 946 reported by bats.

Deliberately not re-hardcoded to today's value — that would just reset the drift clock, which is the actual failure mode here.

For the prose comment there is nothing to derive, so the count is simply dropped. The sentence is about the ~2-minute runtime, which is the part that actually justifies keeping bats out of check.

Why = and not :=

Recursively expanded, so only help pays for the grep — make check is the pre-push path with a sub-60 s budget and shouldn't shell out for a string it never prints.

I checked this rather than assuming it, and the first two ways I tried were both confounded, so for anyone verifying later:

• --eval='BATS_TEST_COUNT = …' is evaluated before the makefile is read, so the file's own assignment overrides it — every result was a false negative.
• A command-line override (make check BATS_TEST_COUNT=…) is expanded regardless, because make propagates it through MAKEFLAGS — a false positive.

The test that actually isolates it is a copy of the real Makefile with only the variable's body swapped for a marker-touching shell:

invocation	marker created?
make check (=)	no — pays nothing
make help (=)	yes — as intended
make check (:=)	yes — why := was not used

Test plan

• make check — green.
• make help — prints 946-test bats suite.
• make bats — 946 tests, 0 failures; matches the derived number.
• grep -nE '\b[0-9]{3}[- ]?tests?\b' Makefile — no matches.

Note

No issue was filed for this — it came in as a direct report. Recent history has precedent for small chores carrying only the PR number (e.g. #684, #667), so I followed that rather than opening a ticket to close it immediately. Happy to file one if you'd rather it were tracked on the board.

🤖 Generated with Claude Code

---

Note

Low Risk
Makefile-only developer UX change with no runtime, CI behavior, or test logic impact beyond accurate help text.

Overview
Fixes stale bats suite counts in the Makefile by deriving the total from scripts/tests/*.bats (^@test lines) into BATS_TEST_COUNT, so make help always shows the current size (e.g. 946) instead of the old hardcoded 868.

Uses recursive = so the grep runs only when help prints the string—make check stays on its fast path without an extra shell invocation. The check target comment no longer cites a fixed test count; it only explains why the full bats run stays in check-all.

^{Reviewed by Cursor Bugbot for commit b856c9f. Bugbot is set up for automated code reviews on this repo. Configure here.}

[shujaatTracebloc]

Approving.

Derivation is right and the = vs := choice is the load-bearing detail — make check is the pre-push path with a sub-60s budget and recursive expansion means it never pays for the grep. Checked the failure mode too: 2>/dev/null plus wc -l means a missing/renamed scripts/tests/*.bats degrades to 0-test, not to a broken help target, and ^@test can't match a commented-out #@test.

Help text only — no runtime path touches this.