Testes de componente para as vistas que nenhum teste renderizava

[qzte]

Ponto #14 do plano de melhorias: a rede de segurança antes de #11 (modularização) e #10–#12 (partir componentes, unificar arquitecturas).

O que faltava

Os 86 testes unitários cobrem funções puras; os grupos de browser cobriam percursos pontuais. O KpisPanel (1200 linhas), o TimesPanel e o AnnualPlanPanel não eram renderizados por nenhum teste. Um erro de render neles não falha nada: o React desmonta a árvore e a vista fica em branco, sem mensagem nenhuma. Refactorizar 2700 linhas sobre isso é aposta, não engenharia.

Cinco grupos novos (21 testes)

Grupo	O que prova
As três vistas renderizam com dados reais	Tempos, Plano Anual, KPIs operacional e executivo, Workflow, e a volta ao Tracking — com um processo real. O cartão PROCESSOS ATIVOS é lido do ecrã e comparado com a sessão
Pesquisa e filtros da lista	O filtered e o contador que o utilizador lê — o par que uma memoização mal feita (#9) põe a discordar sem dar erro
Ida e volta do backup	Exportar pelo caminho de download, eliminar o processo, e voltar a carregar o ficheiro que a própria aplicação escreveu. O envelope é inspeccionado (data, version, annualPlan)
A sessão sobrevive a um refresh	O processo continua lá e o ecrã de arranque não volta; o modo editor não sobrevive — o PIN é pedido outra vez
Plano Anual · da entrada ao processo	Entrada nova → «▶ Iniciar» → o linkedProcessId verificado contra a sessão. É essa ligação que faz os KPIs executivos baterem certo

Um flake pré-existente corrigido

/x é o src dos payloads de XSS destes testes ('<img src=x onerror=…>'). O sanitizador tira o handler e deixa a imagem, que é inerte — mas o browser pede-a na mesma, e o 404 entrava na consola como erro. Contaminava a verificação «nenhum erro de consola» de grupos sem relação nenhuma com ele, de forma intermitente conforme o pedido chegasse antes ou depois da asserção.

O servidor de testes responde-lhe agora 204. Não esconde nada: um recurso da aplicação que falte tem um caminho a sério e continua a dar 404.

npm run ci:full

ci + testes de browser, para correr antes de abrir um PR. O npm run ci fica rápido como estava — é o que se corre a cada alteração.

Uma decisão que vale a pena discutir

O README dizia, com bons argumentos, que o critério para um teste existir é um só: corresponder a uma falha que já aconteceu aqui. Estes testes não cumprem esse critério — são caracterização, não regressão.

Em vez de os acrescentar em silêncio contra a regra escrita, o README passa a documentar dois critérios: a falha que já aconteceu (que continua a ser o principal) e «ser a rede de uma reestruturação planeada», com a justificação explícita. O que continua a não haver é teste escrito por cobertura: um teste que não saiba dizer que falha impede — passada ou futura — não entra.

Se preferires manter o critério único, digo-o já: metade destes grupos não sobrevive a essa regra e o refactor de #10–#12 fica sem rede.

Verificação

npm run ci passa. Nos testes de browser, 62 passam; as 11 falhas são todas ERR_CERT_AUTHORITY_INVALID no Google Fonts — o proxy TLS do ambiente onde isto foi desenvolvido, idêntico em main. Três corridas consecutivas deram exactamente o mesmo resultado (o flake do /x desapareceu). O CI do GitHub é que dá o veredicto sobre as 11.

🤖 Generated with Claude Code

https://claude.ai/code/session_01XwDMNpJzcA3Z2nP3jjwuJd

---

Generated by Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.