test: close Gremlins-flagged gaps (surviving mutants + uncovered code)

Aperta
  • Qualcosa non va?
#290 1 commento 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@ffumero2003 ci sta già lavorando.

Dal 4/11/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

testing

Context

After the test-integrity work landed, a refreshed Gremlins v0.6.0 run on main (c3b00f1, --timeout-coefficient 20 --workers 2, unit tests only, no -race) measured:

Package Test efficacy Mutator coverage Killed / Lived / Not-covered / Timed-out
b2 96.54% 96.66% 754 / 27 / 27 / 17
base 92.44% 78.67% 208 / 17 / 61 / 0

(Up from the #97 baseline of 64.05% / 71.88%.) This issue tracks closing the remaining gaps the run surfaced. Two kinds of work; do them as separate PRs.

Acceptance criteria

  • R1. Part A: a re-run shows the targeted surviving mutants killed (or annotated equivalent); efficacy rises toward the high-90s. Each new test is proven to fail when its production line is reverted.
  • R2. Part B: monitor.go has unit coverage; remaining not-covered lines are either covered or documented as live-only.
  • R3. Depends on the Gremlins CI adoption (#97) landing first so the numbers are reproducible.

In scope

Part A — kill the surviving mutants (tests exist but don't catch a change)

These lines have a mutant that survived — a change there passes every test. Each is a boundary/arithmetic/negation that needs a test asserting the exact behavior (break-per-claim: revert the fix, the new test must fail).

b2 (27 surviving), concentrated in:

  • writer.go: 516, 610, 621, 699, 731, 1017, 1022, 1023
  • reader.go: 266, 269, 286, 459
  • replication.go: 215, 219, 251
  • iterator.go: 102, 108
  • accountinfo.go: 162, 221
  • b2.go: 774 · baseline.go: 414 · compose.go: 274 · progress.go: 49 · sync/sync.go: 351 · copy.go: 162 · backend.go: 101

Also resolve the 17 timed-out b2 mutants (mostly writer.go/reader.go) by raising --timeout-coefficient or trimming the slow test so they report a real killed/lived instead of timing out.

base has 17 surviving mutants; the per-line list was not captured (the baseline base run was not saved). Re-run gremlins unleash --timeout-coefficient 20 --workers 2 ./base to enumerate them before fixing.

Note: some survivors may be equivalent mutants (behavior-identical, uncatchable) — annotate and skip those rather than contorting a test. Target the real ones; 100% is not the goal.

Part B — cover untested code (no test reaches it)

b2 has 27 "not covered" mutants, dominated by:

  • monitor.go: lines 50, 144, 147, 199, 203–205, 226, 230 — the package has effectively no unit tests.
  • lock.go: 65 — file-lock paths (may require live B2).
  • sync/sync.go: 298, 414, 416 · accountinfo.go: 167 · backend.go: 1114 · b2.go: 901 · replication.go: 26

Add hermetic unit tests where possible (monitor.go first); where a path genuinely needs live B2, document that in docs/testing.md rather than forcing a fake.

Out of scope

  • Unrelated work outside the components and behavior described in In scope.

Verification

Run the repository regression checks with live credentials unset:

unset B2_APPLICATION_KEY_ID B2_APPLICATION_KEY B2_ACCOUNT_ID B2_ACCOUNT_KEY
go build ./...
go vet ./...
go test -race -count=1 ./b2/... ./base
  • Use Gremlins v0.6.0 without -race, recording the measured ref and configuration. Preserve the issue's historical baseline as historical, rather than claiming it is a fresh measurement.
  • Apply each targeted mutation independently; record red output for the relevant test and green output after restoration. Explain equivalent mutants instead of contorting tests.
  • Re-run the specified base enumeration: gremlins unleash --timeout-coefficient 20 --workers 2 ./base; record per-package killed/lived/not-covered/timed-out results for the targeted run.
  • For Part B, record covered paths or the documented reason a path needs live B2.
  • Gremlins runs must remain separate from the race-enabled Go regression run.
  • Expected result: the checks above succeed and the observable outcomes in Acceptance criteria are demonstrated. If a check cannot run, report Could not run because: ...; if it starts but fails, report Could not complete because: .... A skipped check is not a pass.

Links

Lingua principale
Go
Stelle
66
Fork
18
Merge medio
1g 10h
PR unite (30g)
132

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Backblaze/blazer

Tutte le issue di Backblaze/blazer

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.