Testes¶
Camadas de validação¶
| Suite | Local | O que especifica |
|---|---|---|
| Domínio | packages/aivaleu_domain/test |
regras puras, estados, validações e casos de uso |
| Dados | packages/aivaleu_data/test |
mapeamento e adapters com mocks/fake Firestore |
| Apps | apps/*/test |
Cubits/BLoCs, widgets, rotas e fluxos visuais |
| UI/Core | packages/aivaleu_ui/test, packages/aivaleu_core/test |
componentes e serviços comuns |
| Functions unitárias | functions/tests |
handlers, autorização e transações com doubles |
| Functions em emulador | functions/tests/emulator |
Rules e concorrência reais no Firestore local |
O monitor waiter_desktop não possui diretório de testes no estado atual. Sua segurança operacional depende principalmente dos testes de waiter_auth, confirm_checkin, repository e Rules.
Comandos locais¶
Na raiz, análise e testes Flutter por package:
dart run melos analyze
dart run melos test
Para isolar uma suite:
cd packages/aivaleu_domain
flutter test
cd ..\..\apps\aivaleu_app
flutter test
Functions sem emulador:
cd functions
npm test
Tests de Rules e concorrência iniciam Firestore Emulator em um projeto demo:
cd functions
npm run test:emulator
O script test:emulator pode abrir processos Java/Firebase locais e usa portas configuradas. Ele não deve alcançar produção; mantenha demo-aivaleu e confira que FIRESTORE_EMULATOR_HOST foi definido pelo emulators:exec.
Como interpretar falhas¶
| Falha | Primeira investigação |
|---|---|
permission-denied em teste de Rules |
identidade/claim, ownership e campos alterados |
| índice ausente | query mudou sem atualizar firestore.indexes.json |
| teste Flutter trava no bootstrap | Firebase inicializado em widget que deveria receber mock |
| callable mock não chamado | região/instância de FirebaseFunctions ou caminho DI incorreto |
| concorrência excede limite | reserva/conversão/liberação fora de transação |
| Jest passa, emulator falha | diferença entre doubles e semântica real do Firestore/Rules |
Testes com efeitos externos¶
Não inclua nos testes automáticos comuns:
- webhook ou Checkout Stripe real;
- deploy Firebase;
grant:super-adminem projeto remoto;- backfill com
--apply; - seed sem hosts de emulador;
- envio de mensagens ou uploads remotos.
Para Stripe local, use modo test e CLI somente numa sessão de homologação explicitamente preparada. A aprovação unitária do handler não prova configuração do webhook, dos Prices ou do Secret Manager.
Cobertura esperada ao alterar fluxos¶
- Entidade/use case: teste unitário de regras e estados-limite.
- Repository/model: serialização, erro do SDK e contrato da callable.
- Function: autenticação, ownership, payload inválido, sucesso e idempotência/concorrência.
- Rules: leitura e escrita permitidas e negadas para cada role.
- UI: loading, vazio, sucesso, erro e retry quando existirem.
Ao finalizar, rode pelo menos as suites afetadas, análise estática e o build estrito desta documentação.