# Estratégia de Testes — Mud Sentinel

**Documento:** `engenharia/03-estrategia-de-testes.md`  
**Versão:** 1.0.0  
**Status:** Vigente

---

## 1. Objetivo

Garantir que regras de domínio, isolamento multi-tenant, auditoria e contratos críticos não regridam — com custo de manutenção sustentável.

---

## 2. Pirâmide de testes

```text
        /\
       /E2E\          poucos, fluxos P0 críticos
      /------\
     /Contract\       APIs, eventos, conectores
    /----------\
   /Integration\      DB, fila, busca (testcontainers)
  /--------------\
 /  Unit/Domain   \   maioria — invariantes e policies
/------------------\
```

**Justificativa:** testes de domínio são baratos e estáveis; E2E pegam wiring real mas são frágeis e lentos.

---

## 3. Tipos e ownership

| Tipo | O que cobre | Dono típico | Ferramenta |
|------|-------------|-------------|------------|
| Unit / Domain | Invariantes, state machines, policies | Dev do módulo | pytest |
| Application | Handlers com ports fake | Dev | pytest |
| Integration | Repositórios, outbox, consumers | Dev | pytest + testcontainers |
| Contract | OpenAPI, schemas de eventos, conector fixtures | Dev + Arquitetura | schemathesis / pact-like / golden |
| Cross-tenant security | Tentativas de acesso cross-tenant | Segurança + Dev | pytest dedicados |
| E2E | Login → busca → dossiê → export | QA/Dev | Playwright |
| Load / soak | Busca, grafo, ingestão | Ops | k6 ou similar |
| AI eval | Qualidade de completions, grounding | Intelligence | golden sets + scores |

---

## 4. Cobertura e gates

| Área | Gate CI |
|------|---------|
| Módulos `domain` core | Linhas críticas cobertas; falha se invariante sem teste |
| `iam`, `tenancy`, `audit` | Cobertura alta obrigatória; testes de isolamento |
| UI | Testes de componentes nos fluxos P0; E2E smoke |
| Meta de coverage global | Indicador, **não** vanidade — foco em risco |

**Justificativa:** percentuais cegos incentivam testes inúteis; gates por módulo de risco são superiores.

---

## 5. Testes multi-tenant (obrigatórios)

Todo repositório/query de negócio deve ter cenário:

1. Tenant A cria recurso.
2. Tenant B tenta ler/alterar → **negado** / não encontrado (sem vazamento de existência quando política exigir).

Falha desses testes bloqueia release.

---

## 6. Testes de auditoria

Para ações sensíveis (login admin, export, mudança de papel, publicação de ingestão):

- Assertiva de que evento de auditoria foi emitido com campos mínimos.
- Assertiva de que payload não contém segredos.

---

## 7. Dados de teste

- Preferir **factories** e **builders** no domínio.
- Proibido usar dados pessoais reais de produção.
- Fixtures de fontes públicas: dumps anonimizados/sintetizados versionados em `connectors/*/fixtures`.

---

## 8. Ambientes de teste

| Ambiente | Uso |
|----------|-----|
| Local | unit + integration leve |
| CI | pirâmide completa possível em tempo orçamentado |
| Staging | E2E + smoke pós-deploy |
| Production | synthetic checks / smoke autenticado limitado |

---

## 9. Flakiness

- Quarentena máxima curta; flake recorrente = bug de produto ou de teste a corrigir.
- Proibido `sleep` arbitrário; preferir waits condicionais / poll com timeout.

---

## 10. Critérios de saída de release

1. CI verde na tag.
2. Smoke E2E P0 em staging.
3. Sem severidade alta/crítica de segurança aberta sem waiver formal.
4. Migrações dry-run ok (quando existirem).