Testes E2E — SGApi

Guia para testes end-to-end do ecossistema SuperApp + SGApi + SG Linear, executados em ambiente de staging/homologação.

---

1. Definição

E2E valida o sistema como o usuário final o utiliza:

SuperApp (mobile) → API SGApi → MySQL → SG Linear ERP (desktop/web)

Diferente da integração:

Aspecto	Integração	E2E
Ambiente	Container Docker local / CI	Staging homologação
Escopo	API + banco	App + API + ERP + rede
Velocidade	Segundos	Minutos
Quantidade	Dezenas/centenas	Poucos fluxos críticos
Objetivo	Regressão técnica	Confiança de release

---

2. Quando usar E2E na SGApi

Use E2E para

• Smoke de release antes de produção
• Fluxos que envolvem múltiplos sistemas (SuperApp sincroniza → ERP reflete)
• Validação visual/UX que integração não cobre
• Homologação com dados realistas (volume, permissões reais, lojas reais)

Não use E2E para

• Cobrir todas as variações de regra (use integração)
• Substituir testes de integração no CI diário
• Debugar bug de SQL/EF (integração é mais rápida)

---

3. Pirâmide — posição do E2E

Integração (CI em todo PR)  ████████████  ← bulk da cobertura
E2E (staging, pré-release)  ██            ← 5–15 cenários críticos

Regra: se um cenário pode ser coberto por integração com MySQL, prefira integração. E2E só quando o valor justifica custo e flakiness.

---

4. Escopo recomendado — SuperApp V2

Tier 1 — Obrigatório antes de release

ID	Fluxo	Validação E2E
E2E-01	Login SuperApp	Token, sessão única, mensagem de sessão encerrada
E2E-02	Ajuste de estoque	App "Sincronizado" + ERP estoque + movimentação
E2E-03	Consulta produto	Código barras retorna saldo coerente
E2E-04	Logout / sessão invalidada	Request com token antigo → 401

Tier 2 — Alta prioridade

ID	Fluxo
E2E-05	Transferência interna
E2E-06	Inventário (abertura + item)
E2E-07	Recebimento mercadoria via cega
E2E-08	Motivos de alteração estoque (sync)

Tier 3 — Conforme módulos entregues

• Cotação, listas avulsas, dashboard, validade produto, etc.

---

5. Ambiente E2E

Requisitos

Componente	Staging
SGApi	Deploy homologação (Docker)
MySQL	BD clone/sandbox do cliente ou base padrão Linear
SuperApp	Build homolog apontando para API staging
SG Linear	Instância conectada ao mesmo banco da API
Usuário teste	Permissões SuperApp conhecidas

Dados

• Loja fixa de teste (ex.: LJ02, es1_empresa = 2)
• Produtos seed documentados (ex.: 33610, barcode 7896306625275)
• Nunca E2E automatizado contra produção de cliente

Configuração documentada

Manter arquivo testes/e2e/ambiente-staging.md (quando implementar) com:

• URL da API
• Credenciais de teste (vault — não commitar senhas)
• IDs de loja/produto/usuário
• Versão mínima do app

---

6. Abordagens de implementação

Opção A — E2E “API + ERP via banco” (recomendada inicial)

Sem automatizar UI mobile no CI:

1. SuperApp manual ou script HTTP reproduzindo sync
2. Assert via SQL ou API GET no ERP/API
3. Operador valida tela ERP opcionalmente

Prós: mais estável, roda em pipeline com permissões limitadas.
Contras: não testa UI do app.

Opção B — E2E mobile (Appium / Maestro / Detox)

Automatiza toques no SuperApp.

Prós: cobertura real do usuário.
Contras: flaky, lento, exige device farm ou emulador no CI.

Opção C — E2E híbrido (recomendado longo prazo)

• CI nightly: Opção A (HTTP + asserts BD)
• Pré-release manual: checklist Opção B em device físico

---

7. Exemplo de cenário E2E-02 — Ajuste de estoque

Pré-condições

• Produto 33610 com saldo conhecido (ex.: 1) na loja 2
• Usuário com permissão estoque
• Motivo "AJUSTE DE ESTOQUE" cadastrado

Passos

#	Ação	Resultado esperado
1	Abrir SuperApp → Ajuste de Estoque	Tela carregada
2	Selecionar loja LJ02	Loja selecionada
3	Informar barcode 7896306625275	Produto exibido
4	Quantidade 3 → Salvar	Sucesso local
5	Sincronizar	Status Sincronizado
6	Abrir SG Linear → produto 33610	Estoque = 3
7	Aba Mov. Estoque	Linha ATUEST / SuperApp
8	Query SQL es1, estoques	es2_qatu = 3, quantidade_atual = 3

Critérios de falha

• App sincronizado mas ERP com saldo antigo → bloqueia release (bug 043447)
• Movimento sem saldo → bloqueia release
• Saldo ok sem movimento → investigar (histórico incompleto)

---

8. Automação HTTP (sem UI) — esboço

Para pipeline staging:

// Projeto: SGApi.E2ETests (opcional, separado de IntegrationTests)
[Fact]
[Trait("Category", "E2E")]
public async Task E2E_AjusteEstoque_Sincronizado_RefleteSaldoNoBanco()
{
    // 1. Login real staging
    var token = await StagingAuth.LoginAsync(usuario, senha);

    // 2. POST ajuste (mesmo contrato SuperApp)
    var response = await _stagingClient.PostAjusteEstoqueAsync(token, payload);

    // 3. Assert API
    response.Should().BeSuccessful();

    // 4. Assert BD staging (read-only user)
    var saldo = await _stagingDb.QuerySaldoAsync(33610, 2);
    saldo.Should().Be(3m);

    // 5. Opcional: API consulta produto
    var produto = await _stagingClient.GetProdutoAsync(token, barcode);
    produto.Estoque.Should().Be(3m);
}

Marcar com [Trait("Category", "E2E")] e excluir do CI de PR (rodar nightly ou manual).

---

9. Checklist manual de release (Tier 1)

Documento operacional para QA quando automação E2E mobile não existir:

## Smoke SuperApp V2 — Homologação — Data: ___

- [ ] E2E-01 Login (sessão única)
- [ ] E2E-02 Ajuste estoque → ERP saldo + movimento
- [ ] E2E-03 Consulta produto
- [ ] E2E-04 Token antigo rejeitado após novo login

Observações:
Versão API: ___
Versão App: ___
BD: ___
Responsável: ___

---

10. Gestão de flakiness

Causa	Mitigação
Rede instável	Retry limitado (1x) só em E2E
Dados compartilhados	Usuário/loja exclusivos E2E
Sync assíncrona	Poll com timeout (ex.: 30s)
Horário/mês movimento	Alinhar data ou criar tabela mov
Cache tenant cloud	Invalidar cache ou aguardar TTL

Nunca aumentar timeout indefinidamente — corrige instabilidade na raiz.

---

11. Segurança

• Credenciais staging em Azure Key Vault / GitHub Secrets
• Não commitar .env com senhas
• Conta E2E com permissões mínimas
• Logs E2E sem CPF/CNPJ reais de clientes

---

12. Métricas sugeridas

Métrica	Meta
Cenários Tier 1 passando	100% antes de prod
Tempo suite E2E staging	< 15 min
Flakiness	< 5% (re-run)
Bugs pós-release em fluxos Tier 1	0

---

13. Relação com outros testes

Unitário     → regra de cálculo (delta estoque)
Integração   → POST API + MySQL container (CI diário)
E2E          → SuperApp + staging + ERP (pré-release)

Bug 043447:

• Integração deveria bloquear no PR
• E2E teria bloqueado no homolog se alguém olhasse só movimento — checklist exige saldo ERP

---

14. Próximos passos de implementação

1. Definir ambiente staging padronizado com seed documentado
2. Criar SGApi.E2ETests ou job manual com traits
3. Automatizar Tier 1 via HTTP + SQL (Opção A)
4. Adicionar checklist manual no processo de release
5. Evoluir para automação mobile quando houver device lab

---

15. Ver também

• Testes de integração
• Setup e infraestrutura
• Sessão única SuperApp
• README testes