Skip to content

Latest commit

 

History

History
85 lines (60 loc) · 2.6 KB

File metadata and controls

85 lines (60 loc) · 2.6 KB

Testes

Sumario

Estrutura

  • tests/functional: testes de fluxo HTTP e autorizacao
  • tests/unit: testes isolados de servicos com mocks

Comandos principais

pnpm test
pnpm test functional
pnpm test unit

Execucao por arquivo

pnpm test functional --files tests/functional/gateways/manage_gateways.spec.ts
pnpm test unit --files tests/unit/services/payment_service.spec.ts

Stress test da rota de purchases

Existe um script dedicado na raiz do projeto para stress test completo do fluxo de compras e reembolsos.

Arquivo:

  • stress-test.sh

O que o script faz

  1. Autenticação → Login automático e obtenção de token
  2. Busca de produto → Extrai um produto válido da API
  3. Stress test de compras → Envia N requisições concorrentes via ab para POST /api/v1/payments/purchases
  4. Monitoramento de fila → Exibe estado do Redis antes e depois das requisições
  5. Aguarda processamento → Countdown de 10s para o worker processar as compras
  6. Reembolsos → Testa reembolso em todas as transações criadas via POST /api/v1/payments/purchases/:id/refund
  7. Relatório → Sumário com status de sucesso/falha dos reembolsos

Exemplos de uso

./stress-test.sh           # padrão: 100 requisições com concorrência 10
./stress-test.sh 300 20    # 300 requisições com concorrência 20
./stress-test.sh 50 5      # 50 requisições com concorrência 5

Saída esperada

O script mostra em tempo real:

  • ✓ Token obtido
  • ✓ Product ID encontrado
  • ✓ Estado da fila Redis antes/depois
  • ✓ Resultado do ab (requisições/s, tempo médio)
  • ✓ Contador regressivo de espera (10s)
  • ✓ Status individual de cada reembolso
  • ✓ Resumo final (reembolsos bem-sucedidos vs. falhas)

Dependências

O script valida a presença de: ab, curl, jq, redis-cli

Diretrizes adotadas

  • Rotas alinhadas com /api/v1
  • Assertivas de status coerentes com middlewares de auth/roles
  • IDs obfuscados nos endpoints que exigem encode/decode
  • Mocks de contratos nos testes unitarios (GatewaySelector, PaymentProcessor, RefundService)

Boas praticas

  • Funcional: validar comportamento externo (status, payload, autorizacao)
  • Unitario: mockar dependencias por contrato e evitar IO externo
  • Evitar acoplamento com dados de seed quando o teste puder criar dados proprios