Mock com Estado: Simulando APIs que Mudam de Comportamento

O problema do mock sem memória

Um mock básico é uma função pura: mesma requisição, mesma resposta, sempre. Isso é ótimo pra testar o formato de um payload, mas quebra na hora de testar fluxos reais — rate limiting, um pedido que muda de status ao longo do tempo, ou um recurso que só existe depois de criado. Pra esses casos, o mock precisa de estado.

O httpdrop tem três mecanismos de estado, cada um pro tipo de cenário certo. Nenhum deles exige código — tudo configurado direto na Mock Rule.

1. K-V Store: contador simples entre chamadas

Cada endpoint tem um espaço de chave-valor persistente, acessível via storeGet, storeSet, storeIncr, storeDecr e storeReset no body da regra. Exemplo clássico: simular rate limiting.

// Mock Rule: GET /limited → 200
{
  "callCount": {{storeIncr 'api_calls'}},
  "allowed": "{{#if (lte (storeGet 'api_calls') 3)}}true{{else}}false{{/if}}",
  "message": "{{#if (lte (storeGet 'api_calls') 3)}}Requisição aceita{{else}}Rate limit excedido{{/if}}"
}

for i in 1 2 3 4 5; do curl -s https://httpdrop.com/mock/SEU_ENDPOINT_ID/limited; echo; done
# Chamadas 1-3: "allowed": true
# Chamadas 4-5: "allowed": false

2. Response Sequences: o mesmo endpoint evolui a cada chamada

Configure uma lista de passos — cada requisição pro mesmo path devolve o próximo da lista, avançando um índice persistido por regra. Ideal pra simular um recurso que muda de status com o tempo, como um pedido sendo processado:

// Mock Rule: GET /pedidos/123 → Response Sequences
[
  { "status": 200, "body": "{\"status\":\"pending\"}" },
  { "status": 200, "body": "{\"status\":\"processing\"}" },
  { "status": 200, "body": "{\"status\":\"shipped\"}" }
]
// Mode: last (fica no último passo depois de esgotar a lista)

As três primeiras chamadas em GET /pedidos/123 devolvem pending, depois processing, depois shipped — e ficam em shipped daí em diante. Combinado com o motor de templates, cada passo também pode variar campos com {{faker.xxx}}.

3. CRUD automático: o estado "de verdade"

Quando o cenário precisa de estado real — criar, listar, atualizar, apagar — uma tabela CRUD é a ferramenta certa em vez de simular manualmente com store/sequences. Um POST /produtos persiste de verdade no SQLite do endpoint; um GET /produtos logo depois reflete o que foi criado — sem escrever nenhuma regra adicional.

Combinando os três

Cenários reais costumam misturar os três: CRUD pro recurso principal, K-V Store pra um contador de tentativas de login, Response Sequences pra simular a evolução de status de um pagamento assíncrono. Nenhum concorrente direto de mock server oferece os três mecanismos prontos — normalmente é K-V Store ou sequências, não os dois integrados com CRUD real.