CASE EM DESTAQUE
Expense Approval Quality Lab
Um colaborador envia uma despesa; um gestor aprova ou rejeita. O laboratório trata esse fluxo como um problema de autorização e de estado, não apenas como um formulário — e usa testes de API e E2E para provar isso.
Problema
O fluxo tem dois papéis — employee e manager — e um estado imutável após a decisão: uma despesa nasce pending e vai para approved ou rejected, sem volta. O problema de engenharia real não é “o caminho feliz funciona”, é: quem pode decidir uma despesa e o que acontece quando alguém tenta contornar essa regra.
Risco
A regra de autorização documentada no laboratório é direta e testável: um gestor só pode decidir despesas de colaboradores que se reportam a ele e, independentemente do papel, ninguém pode decidir a própria despesa. O risco relevante não está no formulário de envio — está na borda de autorização e nas tentativas de violação dela.
Estratégia
Oito cenários documentados, divididos deliberadamente entre camadas: quatro testes de API e quatro E2E. A validação e a autorização — os pontos de maior risco — são comprovadas na camada de API, onde o resultado é determinístico e rápido de checar; a camada E2E cobre apenas o que um navegador precisa observar. Essa divisão está descrita em docs/TEST_STRATEGY.md, no próprio repositório.
Decisões de engenharia
- Autorização e transições de estado validadas em API, não replicadas em E2E, para manter o feedback rápido e determinístico.
- Contas fixas com seed conhecido (dois gestores, dois colaboradores) para tornar os cenários reprodutíveis.
- Escopo explicitamente delimitado: sem testes de performance/carga neste laboratório (ficam no laboratório de API com k6), sem suíte dedicada de acessibilidade, sem cobertura multi-browser — o README documenta essas exclusões como decisão, não como lacuna.
Evidências
- Cenário S4 — “um gestor não pode aprovar a própria despesa” (API, prioridade P0).
- Cenário S5 — “um colaborador não pode chamar o endpoint de aprovação” (API, prioridade P1).
- Cenário S7 — listagem de despesas com escopo por papel/time (API, prioridade P1).
- Cenário S8 — uma despesa decidida não pode ser editada pelo dono (E2E, prioridade P2).
- CI (
.github/workflows/tests.yml) executa, em ordem, typecheck → lint → testes de API → testes E2E, com evidência (relatório e traces do Playwright) publicada como artefato em caso de falha.