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

CI: add a mutation check — 11 mutations across #222/#223/#224 left the suite green

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

Los mantenedores suelen responder en 4 días

Nadie ha tomado este issue todavía.

Evaluación

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

Línea de trabajo

Comienza con un spike de runtime usando @stryker-mutator/core y su compatibilidad con vitest, midiendo las ~1,090 pruebas existentes en packages/outpost. Después, evalúa la cobertura de las líneas modificadas en packages/outpost/** y apps/** frente a los commits registrados de CPK-8037. Se considera terminado cuando se detectan las cuatro clases de mutación indicadas y la comprobación se mantiene acotada para la CI requerida.

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

Descripción

area: infrastructure roadmap roadmap: next

Why

A review round on 2026-08-20 across three open PRs found eleven mutations that delete a claimed fix while leaving the test suite green. Every one was a test that read as coverage and was not.

The distribution matters more than the individual cases:

  • Several were in newly added code, i.e. the tests written alongside a fix did not pin that fix.
  • Two were worse than absent coverage, because the test documents the behaviour it fails to pin — a future reader treats it as proof, and a reviewer treats it as reviewed.
  • One survived removing the exact line the test is named after.

This is not a review-diligence problem. It survived a seven-agent review on the largest of the three PRs until mutation testing was enforced, and the same round produced several confidently-stated findings that were wrong for the same underlying reason: claims about what a test would do, asserted without running it.

Specifics per PR are in CPK-8037, kept there rather than here.

What to build

A CI check that, for source lines a PR touches, applies mechanical mutations and fails if the suite still passes.

Priority order, based on which classes actually caught real gaps in the review round:

  1. Predicate relaxation — comparison operators widened, a truthiness check substituted for a normalising one, a regex anchor dropped. Cheapest to implement, caught the most.
  2. Guard deletion — remove a newly added early-return or throw.
  3. Call-site un-wiring — where a diff extracts a helper and calls it, revert the call site while leaving the helper defined and exported. This is the class a human reviewer is least likely to imagine, and it produced a full-green suite twice in one day.
  4. await removal on newly added awaits.

Scope to changed lines, not the tree, or the runtime is unbounded.

Known limit, worth designing around

Assertions made against strings that are never executed are the structural blind spot this cannot close. Where a query or template is built as text and the dependency is mocked, a substring assertion can be satisfied by an unrelated occurrence while a real semantic mutation passes through. Mutation testing catches "this test cannot fail"; it does not catch "this test asserts the wrong thing about text it never runs." Closing that needs execution against a real dependency, which is separate work.

Acceptance

  • Runs on PRs touching packages/outpost/** and apps/**
  • The mutation classes above are detected as survivors when run against the relevant pre-fix commits (recorded in CPK-8037)
  • Bounded enough to sit in the required check set rather than a nightly

@stryker-mutator/core supports vitest and is the obvious starting point, but spike the runtime first — packages/outpost alone is ~1090 tests and mutation runs multiply that.

Lenguaje dominante
TypeScript
Estrellas
10
Forks
4
Merge medio
4 d 2 h
PR fusionados (30 d)
7

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

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 CopilotKit/outpost

Todos los issues de CopilotKit/outpost

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.