Background
Após #169 mergeado (coverage 16.86%, floor 15), o próximo bloco de ROI é os sprints médios. Três sprints, mais arquivos cobertos, mais esforço por sprint que os easy-wins.
Sprints (cada um = 1 commit no PR único)
Sprint E — Extração + testes de helpers em ffc-core.js + ffc-frontend-helpers.js
Os 2 arquivos juntos somam ~956 LOC zerados. Em vez de testar in-place, extrair os helpers puros (validadores, formatters, parsers) pra módulos próprios — mesmo padrão do S2 de #163 com analyzeDateTimeOrder.
Candidatos de extração (a confirmar lendo o código):
- Validadores: CPF, RF, email
- Formatters: data BR, hora HH:MM, moeda
- Parsers: URL query, hash fragment
- Sanitizers / escape helpers
Resultado esperado: 2-4 novos arquivos ffc-*-helpers.js testáveis a 100%, cada original perde 30-50% do tamanho.
Target: cobertura nos arquivos extraídos 100%, originais 30-50%. ~30 testes.
Sprint F — Cobrir ffc-dynamic-fragments.js (212 LOC)
Script que faz fetch+merge de payload dinâmico no DOM (refresh de stale data). Side-effect-only, sem API pública.
Testes via mock de $.ajax (mesmo padrão de audience-join).
Target: 60-70%. ~10 testes.
Sprint G — ffc-device-signals.js (243 LOC) + ffc-frontend.js (499 LOC)
- device-signals: coleta sinais do browser (canvas hash, audio context, WebGL, screen, timezone, etc.) pra rate-limit por device. Security-relevante. Testar via mock dos APIs do browser (canvas, webgl, audio).
- frontend.js: hub do form processing — captura submit, monta payload, faz POST. Cobertura focada em validação + montagem de payload; AJAX mockado.
Target: device-signals 60%+, frontend.js 50%+. ~25 testes.
Sprint H — Floor ratchet
Após E+F+G, mede baseline. Estimativa: 16.86% → 30-40%. Floor sobe pra ~28-38% mantendo buffer.
Estimativa total
| Sprint |
Testes |
Tempo |
| E |
~30 |
8-10h |
| F |
~10 |
3h |
| G |
~25 |
6-8h |
| H |
— |
15min |
| Total |
~65 |
17-21h |
Out of scope
Branch / PR
- Branch:
claude/js-coverage-medium
- One PR with sprints E-H as separate commits.
Acceptance
Background
Após #169 mergeado (coverage 16.86%, floor 15), o próximo bloco de ROI é os sprints médios. Três sprints, mais arquivos cobertos, mais esforço por sprint que os easy-wins.
Sprints (cada um = 1 commit no PR único)
Sprint E — Extração + testes de helpers em
ffc-core.js+ffc-frontend-helpers.jsOs 2 arquivos juntos somam ~956 LOC zerados. Em vez de testar in-place, extrair os helpers puros (validadores, formatters, parsers) pra módulos próprios — mesmo padrão do S2 de #163 com
analyzeDateTimeOrder.Candidatos de extração (a confirmar lendo o código):
Resultado esperado: 2-4 novos arquivos
ffc-*-helpers.jstestáveis a 100%, cada original perde 30-50% do tamanho.Target: cobertura nos arquivos extraídos 100%, originais 30-50%. ~30 testes.
Sprint F — Cobrir
ffc-dynamic-fragments.js(212 LOC)Script que faz fetch+merge de payload dinâmico no DOM (refresh de stale data). Side-effect-only, sem API pública.
Testes via mock de
$.ajax(mesmo padrão deaudience-join).Target: 60-70%. ~10 testes.
Sprint G —
ffc-device-signals.js(243 LOC) +ffc-frontend.js(499 LOC)Target: device-signals 60%+, frontend.js 50%+. ~25 testes.
Sprint H — Floor ratchet
Após E+F+G, mede baseline. Estimativa: 16.86% → 30-40%. Floor sobe pra ~28-38% mantendo buffer.
Estimativa total
Out of scope
ffc-csv-download.js(668 LOC) +ffc-reregistration-frontend.js(507 LOC) — Sprint próprio (pesado, File API).ffc-admin.js, field-builder, etc.) — Sprint próprio.ffc-audience.js(skipped via [Skipped] Sprint J — split ffc-audience.js (won't do, see body) #167).Branch / PR
claude/js-coverage-mediumAcceptance
npm run test:js≥ 180 tests (era 127).npm run test:js:coverageoverall ≥ 28%.lint.ymlratchets pra valor ~1.5-2% abaixo do novo baseline.