Testes E2E (Playwright)
A suíte E2E vive no front (HSBR-Gestao-Ativos-Front/e2e/). Há dois jeitos
de rodar: tudo automatizado via Docker, ou rápido contra um ambiente já rodando.
Comandos (o caminho simples)
cd HSBR-Gestao-Ativos-Front
# Full E2E via Docker: sobe DB limpo + migrate + seed → builda o container do
# back → builda/roda o front → roda TODOS os specs → derruba tudo. Nada manual.
npm run test:e2e:docker # Postgres (padrão)
npm run test:e2e:docker:sqlserver # SQL Server (= ... -- --sqlserver)
# Rápido: roda o Playwright contra o seu .env / stack JÁ de pé (NÃO sobe DB,
# back nem front). Pede confirmação se o backend não for local.
npm run test:e2e:local
npm run test:e2e:local -- e2e/produtos.spec.ts # focar um spec
Os scripts chamam bash (o harness é um script bash). No Windows funciona porque
o Git Bash (bash.exe) está no PATH. Precisa de Docker para os :docker.
Onde as imagens vêm? (build local vs GHCR)
Resposta curta: com os scripts test:e2e:docker* (que usam --build), o back
é buildado do seu checkout local — então mudanças full-stack (front + back)
são testadas sem precisar fazer merge/publish da API antes.
| Componente | Origem | Build ou pull? |
|---|---|---|
| Banco | postgres:16-alpine / mcr…/mssql:2019 | pull do registry; migrado+seedado a cada run |
Backend (--build) | ../HSBR-Gestao-Ativos-Back (working tree atual) | build local (DB_ENGINE assado) → testa suas mudanças, commitadas ou não |
Backend (sem --build) | ghcr.io/…:develop | pull → testa a imagem publicada (faça merge+publish antes) |
| Frontend | fonte local | build local (npm run build && start), salvo --skip-build |
Atenção: o --build builda o back a partir da pasta irmã
../HSBR-Gestao-Ativos-Back como ela está agora — garanta que esse repo está
na branch/mudanças que você quer testar.
Flag --explain
Na dúvida sobre o que será buildado vs puxado, peça o plano (não roda nada):
npm run test:e2e:docker -- --explain
npm run test:e2e:docker:sqlserver -- --explain
Ele imprime, para o engine/flags escolhidos, se o backend será BUILT from local source ("suas mudanças locais SÃO testadas; não precisa fazer merge/publish da API") ou PULLED from GHCR, e sai.
Flags do harness (run-e2e.sh)
npm run test:e2e:docker -- <flags> repassa as flags. As principais:
| Flag | Efeito |
|---|---|
--sqlserver / --postgres / --engine=<e> | Escolhe o engine (default postgres). Para SQL Server, faz o wiring do override de compose automaticamente — sem EXTRA_COMPOSE. |
--build | Builda o back do fonte local (os scripts :docker já usam). |
--explain | Mostra a origem das imagens e sai. |
--skip-build | Reaproveita o .next já buildado do front. |
--smoke-only | Só e2e/smoke.spec.ts (valida o encanamento DB→back→seed→front→auth). |
--no-teardown | Deixa o stack de pé para iterar. |
e2e/foo.spec.ts, -g "..." | Qualquer arg não-flag vai direto pro playwright test (rodar um subconjunto). |
Exemplos:
# Só os specs que mexem com etiquetas, em SQL Server, reaproveitando o build do front:
npm run test:e2e:docker:sqlserver -- --skip-build e2e/etiquetas.spec.ts
# Repetir um spec 4x (caçar flakiness):
npm run test:e2e:docker -- --skip-build e2e/etiquetas.spec.ts --repeat-each=4
O modo local com confirmação
npm run test:e2e:local roda o Playwright contra o NEXT_PUBLIC_URL_BASE_APP
do seu .env — útil quando você já tem front + back de pé. Como a suíte cria e
altera dados, se esse backend não for local (localhost/127.0.0.1) ele
avisa e pede confirmação (yes) antes de rodar. Para CI/non-interativo:
E2E_CONFIRM=1.
Detalhes
- Roda com
PW_WORKERS=1por padrão (paralelo é flaky com DB/API compartilhados). - Login E2E:
test@email.com/123123(criado pelo seed do back). - O DevOps/CI roda o harness em
--smoke-only; o full vira verde por engine.