test(e2e): trazar cada spec a su historia funcional y medirlo en CI (TD-012) - #22
Merged
Merged
Conversation
…TD-012) El tracker declaraba 25 historias «Implemented / usable» y nada lo comprobaba: 84 casos e2e y exactamente uno nombraba una historia. Tres de esas 25 estaban rotas de verdad el 2026-08-10 —FS-20/FS-13 guardaban false en todo parámetro booleano, FS-05 enviaba undefined como id— y las tres seguían en verde. Cada spec declara ahora a qué historias responde en su primera línea (`// @story FS-05, FS-24`) y `verificar-cobertura-historias.mjs` deriva la cobertura DEL CÓDIGO, contrastándola con la tabla del propio tracker. Se descartó un fichero de mapeo aparte: se habría desincronizado igual que todo lo demás que registra este documento. Primera medición: 11 de 25 cubiertas, 14 no. Cubiertas FS-01 02 03 04 05 13 14 17 20 24 40 Sin ninguna FS-06 07 08 09 10 11 15 16 18 19 21 22 38 39 El mapeo se hizo caso por caso, no por nombre de fichero, y eso importa: `profile-panel.spec.ts` suena a FS-05 y sus doce casos son todos avatar y drawer. Por nombre le habría acreditado a FS-05 una cobertura que no tiene. Tres specs no responden a ninguna historia —authorization-ui, navigation, profile-panel— y es legítimo: prueban mecánica de interfaz, no resultados de negocio. Es INFORME, no puerta. Con 14 de 25 sin cubrir, un gate nacería en rojo, y un gate que nace en rojo se aprende a ignorar. Sí falla en una condición: que una spec se etiquete con una historia que el tracker no declara usable — eso es un error de etiqueta, y una prueba que dice cubrir algo no reconocido es peor que no etiquetar. Promoverlo a puerta (--estricto) es decisión para cuando las 14 estén cerradas. La brecha de fondo sigue abierta; lo que cambia es que el número se mide en cada corrida en vez de suponerse. Verificado: vitest 1626/1626, typecheck 0, build OK, eslint 0 errores. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Resuelve TD-012. El tracker declaraba 25 historias «Implemented / usable» y nada lo comprobaba: 84 casos e2e y exactamente uno nombraba una historia.
Tres de esas 25 estaban rotas de verdad el 2026-08-10 —
FS-20/FS-13guardabanfalseen todo parámetro booleano,FS-05enviabaundefinedcomo id de usuario — y las tres seguían en verde.Cómo
Cada spec declara en su primera línea a qué historias responde:
// @story FS-05, FS-24scripts/verificar-cobertura-historias.mjsderiva la cobertura del código y la contrasta con la tabla del propio tracker. Se descartó un fichero de mapeo aparte: se habría desincronizado igual que todo lo demás que registra el documento de deuda.Primera medición: 11 de 25
El mapeo se hizo caso por caso, no por nombre de fichero, y eso importa:
profile-panel.spec.tssuena a FS-05 y sus doce casos son todos avatar y drawer. Por nombre le habría acreditado a FS-05 una cobertura que no tiene.Tres specs no responden a ninguna historia —
authorization-ui,navigation,profile-panel— y es legítimo: prueban mecánica de interfaz, no resultados de negocio.Informe, no puerta
Con 14 de 25 sin cubrir, un gate nacería en rojo — y un gate que nace en rojo se aprende a ignorar.
Sí falla en una condición: que una spec se etiquete con una historia que el tracker no declara usable. Eso es un error de etiqueta, y una prueba que dice cubrir algo no reconocido es peor que no etiquetar nada.
Promoverlo a puerta (
--estricto) es decisión para cuando las 14 estén cerradas.Lo que NO cambia
La brecha de fondo sigue abierta: 14 historias se declaran usables sin nada que las ejercite de extremo a extremo. Lo que cambia es que ese número se mide en cada corrida de CI en vez de suponerse.
Verificación
vitest1626/1626 ·typecheck0 ·buildOK ·eslint0 errores🤖 Generated with Claude Code