Conclusão da Automação — Estado Atual
Atualizado em 02/09/2026. "Feito" é contagem exata (direto dos arquivos). "Falta" é estimativa — ver a régua usada em cada linha da tabela abaixo e o detalhe no fim da página.
Falta — API / Postman
Régua usada em quase toda linha: 2 testes por endpoint (sem autenticação / com autenticação inválida) — mesma convenção já aplicada aos 7 endpoints que já têm esse teste hoje.
| # | Falta | Situação hoje | Estimativa |
|---|---|---|---|
| 1 | PUT .../configuracoes/boleto — usado em produção por 5 specs, nunca teve teste de autenticação |
Maior prioridade da lista | 2 testes |
| 2 | ~19 rotas de /adm/contas-digitais/* |
Existem no Postman, nunca usadas em teste nenhum | ~38 testes |
| 3 | 7 rotas de /adm/conta-digital-api/* |
Idem | ~14 testes |
| 4 | 6 grupos de rota em /api/v1 (contas-correntes-subconta, remessa/requisicao, termo-aceite, origem-movimentacao, transfeera/*, legal-person/*) |
Idem | ~12 testes |
| 5 | Collection de contrato (Postman) ainda roda manual | Pronta, não plugada em CI | não conta como teste novo |
Subtotal estimado, API/Postman: ~66 testes.
✅ Os 3 cenários de cross-tenant de alta prioridade (Buscar Boletos, Criar Condomínio, Criar Conta
Corrente ADM) saíram desta lista — escritos e rodados de verdade em 02/09/2026
(contaDigitalCrossTenant.cy.js). Achado real: Buscar Boletos e Criar Condomínio confirmaram a
mesma falha de posse já vista em Gerar/Cancelar Boleto (aguardando correção do produto); Criar
Conta Corrente ADM confirmou estar protegido.
Detalhe, por trás dos números
O que já foi feito no Core, por tipo de teste (clique pra expandir)
Os 131 testes de tela (Core), por categoria — o que cada uma responde, e quando rodar na prática:
| Tipo | Qtd | Responde | Quando rodar |
|---|---|---|---|
| UX (alinhamento, largura, responsividade) | 39 | O campo está no lugar certo, do tamanho certo, e não quebra em mobile? | Depois de mudar CSS/layout nas telas mapeadas — sem custo, roda solto |
| Pontual — com dado real | 27 | A regra de negócio funciona de ponta a ponta, criando Administradora/Condomínio/Boleto de verdade? | Deliberado, com cuidado — cria dado real, não é pra rodar à toa |
| Smoke | 26 | Toda tela do menu carrega, sem quebrar? | Logo depois de qualquer deploy em homologação — 1º filtro |
| Pontual — sem dado real | 19 | Mesma pergunta acima, em telas só de consulta (sem criar nada) | Livre, a qualquer momento — sem risco |
| Regressão | 12 | Um bug de UI já confirmado antes voltou a acontecer? | Depois de mexer numa área com bug já confirmado, ou como guarda periódica |
| Sanity | 6 | Depois de um deploy pontual, a área afetada ainda responde? | Logo após deploy pontual — só o módulo afetado |
| Performance | 2 | O tempo de carregar um passo crítico (login, expandir menu) está dentro do esperado? | Periódico ou sob demanda — hoje é relatório, não trava nada |
Total: 131.
Como cheguei em 72% (clique pra expandir)
Feito (167, contado, não estimado):
- 131 testes de tela — todo
it()do Cypress que abre o navegador e interage com o Core (smoke, sanity, regressão, pontuais, UX, performance). - 19 testes de API direta —
autenticacaoObrigatoria.cy.js(14),boletoGuidExistenteRegressao.cy.js(2) econtaDigitalCrossTenant.cy.js(3, novo — 2 confirmaram achado real, 1 confirmou proteção). - 17 requisições de contrato — collection Postman só-leitura, via Newman.
Falta (~66, estimado): só do lado de API/Postman — 2 (endpoint usado sem teste) + 38 (19 rotas ADM × 2) + 14 (7 rotas ADM × 2) + 12 (6 grupos api/v1 × 2).
Conta final: 167 ÷ (167 + 66) = 167 ÷ 233 = 72%.
Como isso roda na prática — 3 cenários do dia a dia (clique pra expandir)
Sem CI plugado ainda (ver item bloqueado na lista de "falta"), quem decide o que rodar e quando é o time, na mão. A régua de fundo em qualquer cenário: smoke primeiro sempre (mais barato, mais rápido — corta o resto se já quebrou), pontual com dado real por último e só quando justifica (mais caro, cria dado de verdade, irreversível), o resto no meio, na ordem que faz sentido pro que mudou.
1. Time do produto acabou de fazer deploy em homologação
npm run cy:run:smoke # 1º filtro — se falhar, para aqui
npx cypress run --spec "cypress/e2e/sanity/boletoSanity.cy.js" # só o módulo que mudou
npx cypress run --spec "cypress/e2e/casos_de_teste/boletoRegressao.cy.js" # bug antigo não voltou?
npx cypress run --spec "cypress/e2e/regressao/contaCorrente/**/*.cy.js" # regra de negócio, módulo que mudou
npm run cy:run:ux # só se mudou CSS/layout
Só roda um spec de dado real (ver SPECS_COM_DADOS_REAIS em scripts/specs-utils.js) se o deploy
realmente mexeu nesse fluxo de ponta a ponta — decisão consciente, não rotina. Terminando, confere
docs/falhas-pendentes.md — se algo falhou de verdade (não é o cold-boot já conhecido), investiga
antes de considerar "passou".
2. Dia comum, sem deploy nenhum — sentinela
npm run cy:run:regressao # ex.: 1x por semana — toda regra de negócio confirmada continua passando?
npm run cy:run:casos-de-teste # bug antigo não voltou?
npm run cy:run:performance # amostra de tendência, acumula com as anteriores
Baixo esforço, roda sozinho, só confere o resultado depois.
3. Desenvolvendo/ajustando um Page Object
Abre só o spec relevante no cypress open (modo interativo) — só se ele não estiver em
SPECS_COM_DADOS_REAIS (scripts/specs-utils.js). Nunca deixa um spec de dado real aberto assim
(cada save re-executa e cria dado real de novo); se precisar rodar um deles durante o
desenvolvimento, roda manual, 1 vez, headless.