test: adopt the b2wiretest strict mode in tests that assert exact request counts

Aperta
  • Qualcosa non va?
#324 0 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@ffumero2003 ci sta già lavorando.

Dal 9/11/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

testing

Context

#305 adds an opt-in strict mode to internal/b2wiretest that fails a test on an extra request after the script is exhausted and, where a test opts in, on a scripted response that was never requested. #305 delivers the tool and its own tests only; no existing SDK test uses it, so on its own it catches no new SDK bug.

Today the fake server repeats the last scripted response forever, so a test can pass while the SDK sends the wrong number of requests (for example retrying too many times) or leaves a scripted response unused.

Acceptance criteria

  • R1. Every candidate above is either converted to strict mode or has a one-line comment or PR note explaining why it was left alone.
  • R2. When a manual len(srv.Calls(...)) != N assertion is converted, the strict-mode expectation matches the number the test already asserts — cross-check against the existing count, do not just delete the manual assertion and trust the new mode.
  • R3. A test that fails under strict mode is reported, not silently re-scripted: the PR description lists each one and says whether the expectation was wrong or the SDK sends a different number of requests than intended. A genuine SDK discrepancy gets its own issue instead of being fixed inside this change.
  • R4. No assertion is weakened, no test is deleted or skipped, and go test ./... passes.
  • R5. Tests that rely on the last response repeating (for example TestNewBucketCORSAndFileLock) still pass unchanged.

In scope

Audit the tests whose intent includes an exact request count and opt each one into the #305 strict mode. Two candidate groups, strongest first:

1. Tests that already count requests by hand (strongest candidates).
The suite has ~64 .Calls(...) usages in b2/ and base/, a subset of them exact-count assertions of the form len(srv.Calls("<call>")) != N. A test already asserting a count is the clearest case for strict mode: the intent to count is explicit, and strict mode enforces it at the source instead of after the fact. Find them with git grep -nE '\.Calls\(' -- 'b2/*_test.go' 'base/*_test.go' and focus on the len(...Calls...) comparisons. Example: b2/a_transfer_termination_test.go:240 (len(srv.Calls("b2_list_parts")) != 1), inside TestResumeStopsAtFinalPartPage.

2. Tests that script an ordered response sequence (ReplySequence).
Scripting an ordered list of responses already implies an expected request count. Call sites (line numbers as of main when filed):

  • b2/a_transfer_termination_test.go:229 (b2_list_parts)
  • b2/b2_test.go:59, b2/b2_test.go:63 (b2_list_buckets, b2_create_bucket)
  • b2/bucket_creation_wire_test.go:66, :149 (b2_list_buckets)
  • b2/live_only_calls_wire_test.go:146 (b2_list_keys)
  • b2/reauth_options_wire_test.go:23, :27 (b2_authorize_account, b2_list_buckets)

Retry, resume, and re-authorization tests fall in one or both groups and are the highest-value targets, since their whole purpose is how many times a call happens.

For each test, decide whether an exact count is part of its intent. Opt in only where it is; leave tests that deliberately rely on the last response repeating unchanged, and note why.

  • opting existing tests into the #305 strict mode; fixing expectations that are wrong.

Out of scope

  • changing the strict-mode API (that is #305); the roughly 124 Reply(...) call sites that repeat one response by design, unless a test already asserts a request count; changing SDK behavior.

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
  • Cross-check each adopted strict expectation against the existing manual request count. For each candidate, record conversion or the reason it remains repeatable.
  • Show that an unexpected extra/missing request fails the adopted expectation; restore the intended request sequence and show green.
  • Report strict-mode discrepancies as required by the acceptance criteria; do not silently rescript or fix SDK behavior here.
  • 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

  • Depends on: #305 (strict mode in internal/b2wiretest)
  • Related: #178 (non-idempotent writes after ambiguous failures), which will rely on exact request counts
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.