Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Expose expected-vs-emitted check coverage per scenario

Abierto
  • ¿Algo no está bien?
#451 5 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 7 días

@AmirK-S ya está trabajando en esto.

Desde el 29/9/2026.

  • #537 de @AmirK-S — abierto
  • #538 de @mohammedmessaoudene-cmd — abierto

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
48/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
typescript
Área
cli, testing-qa

Línea de trabajo

Rastrea cómo Scenario y ClientScenario definen o ejecutan comprobaciones y, después, sigue la construcción de resultados hasta los resúmenes del terminal y la salida legible por máquinas. Revisa primero los casos de setup-failure y passing thin-scenario. Se considera terminado cuando la cobertura esperada y emitida que cumple los requisitos se informa de forma coherente, los gates de aplicabilidad no crean brechas falsas y ambos casos tienen tests.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
TypeScript
Estrellas
130
Forks
107
Merge medio
8 d 19 h
PR fusionados (30 d)
2

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de modelcontextprotocol/conformance

Todos los issues de modelcontextprotocol/conformance

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.