Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Expose expected-vs-emitted check coverage per scenario

Aperta
#451 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
48/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
cli, testing-qa

Direzione di ricerca

Traccia come Scenario e ClientScenario definiscono o eseguono i controlli, quindi segui la costruzione dei risultati fino ai riepiloghi del terminale e all’output leggibile dalle macchine. Esamina prima i casi setup-failure e passing thin-scenario. Il lavoro è completato quando la coverage prevista ed emessa che rientra nei criteri di idoneità viene riportata in modo coerente, gli applicability gate non creano lacune false ed entrambi i casi hanno dei test.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

A scenario can emit only a thin subset of its checks while the reported denominator makes that subset look complete.

The concrete case from mcpkit: auth/authorization-server-migration reported 2 passed, 1 failed for months. The initial wire handshake failed, so roughly 76 other checks never emitted. PR #327 makes the setup failure explicit, but the result still cannot show how much of the scenario did not run.

The harder case has no setup failure: setup succeeds, only accept-path checkpoints emit, and the thin scenario result passes.

Add a per-scenario expected-vs-emitted coverage signal to the upstream results. It should be visible in both terminal summaries and machine-readable output. A count is enough to expose the gap; stable IDs would also identify the missing checks.

Today Scenario and ClientScenario do not declare their expected check IDs, and some checks are dynamic or version-gated. The implementation will need a stable expected set or another baseline that excludes checks which are not applicable to the selected spec version or extension.

Acceptance criteria:

  • Every executed scenario reports expected and emitted check counts, or equivalent coverage data.
  • Missing eligible checks remain visible when every emitted check passes.
  • Machine-readable results expose the coverage signal for downstream consumers.
  • Spec-version, extension, and documented applicability gates do not create false gaps.
  • Tests cover both a setup failure and a passing thin-shadow result.
  • SDKs do not need to maintain their own per-scenario count snapshots.

@panyam offered to implement this in #327.

Prior art: https://github.com/panyam/mcpkit/pull/1115

Lingua principale
TypeScript
Stelle
127
Fork
101
Merge medio
4g 7h
PR unite (30g)
6

Guida per i contributori

Apri la guida per i contributori

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 modelcontextprotocol/conformance

Tutte le issue di modelcontextprotocol/conformance

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.