Mocking e stubs para integrações

1) Por que é preciso moka e braços

• isolar a lógica do serviço do ambiente instável;
• determinar respostas e erros;
• reproduzir malas de limite raras (timeouts, 429/5xx, não-conservação);
• iniciar testes localmente e em CI é rápido e previsível.

2) Termos e taxonomia

O Stub é uma simples armadilha de resposta fixa, sem verificação de interações.
Mock é um objeto que aguarda e confere chamadas (ordem/quantidade/argumento).
Fake - Implementação simplificada (por exemplo, um repositório In-Memory) com comportamento real.
Spy é um embrulho que registra chamadas reais.
O Service Virtualization é um serviço externo «virtual» com cenários, status e características de rede.
Record/Replay - Gravação de tráfego real e reprodução posterior (filtros/edição).

3) Pattern arquitetônicos para testabilidade

Ports & Adapters (Hexagonal): leve a integração por interfaces - facilmente trocada por fake/mock.
Camada anti-corrupção (LCA): Um módulo traduz o modelo externo para o domínio - menos pontos de mooca.
Clientes Contract-aware: geração de OpenAPI/Protobuf → menos discrepâncias manuais.
As bandeiras de função e os modos sandbox são chaves seguras/endpoint para o provedor de estaca.

4) HTTP: ferramentas e exemplos

4. 1 WireMock (standalone/Java DSL)

json
{
"request": { "method": "POST", "urlPath": "/v1/payouts", "headers": { "Idempotency-Key": { "matches": ".+" } } },
"response": {
"status": 201,
"headers": { "Content-Type": "application/json" },
"jsonBody": { "id": "po_123", "status": "queued" },
"fixedDelayMilliseconds": 80
}
}

java stubFor(post(urlEqualTo("/v1/payouts"))
.withHeader("Idempotency-Key", matching(".+"))
.withRequestBody(matchingJsonPath("$.amount", equalTo("100. 00")))
.willReturn(aResponse(). withStatus(201). withHeader("Content-Type","application/json")
.withBody("{\"id\":\"po_123\",\"status\":\"queued\"}")));

4. 2 MockServer (dinâmica/verificação)

json
{
"httpRequest": { "method": "GET", "path": "/v1/wallets/w123" },
"httpResponse": { "statusCode": 200, "headers":[{"name":"Content-Type","values":["application/json"]}],
"body": { "id":"w123","currency":"EUR","balance":0 } }
}

4. 3 Hoverfly (middleware, record/replay)

Anote o tráfego contra o «banco de areia» do provedor, limpe o PII, verifique como fixture.
No modo Simulate, adicione as variações: 200/4xx/5xx, atrasos e «flaky» da janela.

4. 4 Node (Nock) / Python (responses) / Go (`httptest`)

js nock('https://psp. example. com')
.post('/v1/payouts'). reply(201, { id:'po_123', status:'queued' })
.post('/v1/payouts'). reply (409, {code: 'duplicate'}) ;//second call - conflict

go srv:= httptest. NewServer(http. HandlerFunc(func(w http. ResponseWriter, r http. Request){
if r. Header. Get("Idempotency-Key") == "" { w. WriteHeader(400); return }
w. Header(). Set("Content-Type","application/json")
w. WriteHeader(201); w. Write([]byte(`{"id":"po_123","status":"queued"}`))
}))
defer srv. Close()

5) gRPC/Protobuf

5. 1 Geração de estiagem

Gere um servidor por '.proto' e implemente métodos com respostas controladas.
Verifique os metadados (headers), os estatais ('codes. InvalidArgument`, `codes. DeadlineExceeded`).

go type FakePayouts struct{ pb. UnimplementedPayoutsServer }
func (f FakePayouts) Create(ctx context. Context, in pb. PayoutReq)(pb. PayoutRes,error){
if in. Amount <= 0 { return nil, status. Error(codes. InvalidArgument,"amount>0") }
return &pb. PayoutRes{Id:"po_123", Status:"QUEUED"}, nil
}

5. 2 grpcurl para negativos

grpcurl -plaintext -d '{"amount":0}' localhost:50051 payouts. Payouts/Create

6) Mensagens e striptease: Kafka/RabbitMQ

6. 1 Moki-aware Schema

Use o Schema Registry e valide o Avro/JSON-Schema/Protobuf nos testes.
Teste de produção: a mensagem corresponde ao padrão; Teste Consumer: aceita versões antigas e novas.

6. 2 Testcontainers (por exemplo, Kafka + Registry)

java
KafkaContainer kafka = new KafkaContainer(DockerImageName. parse("confluentinc/cp-kafka:7. 6. 1"));
kafka. start();
//We publish the event and wait for consumption with deduplication by key

6. 3 Negativos

Duplicação, mudança de ordem, atraso na entrega, mensagens «venenosas» (dead-letter).
Mensagens grandes (near-limit), versões não reconhecidas dos circuitos.

7) Contracto-aware braços

7. 1 Pact (CDC mocks)

O consumer gera a expectativa → o arquivo pact → provider é verificado no estande.
O Pact stub server reproduz as expectativas para os testes de integração do cliente.

7. 2 OpenAPI/Protobuf → geração de estacas

Ferramentas que levantam o servidor mico a partir da especificação (por exemplo prism, openapi-mock, grpc-mock).
Inclua exemplos negativos/códigos na especificação, que também é um contrato.

8) Rede e caos: simulação de falhas

Atrasos e jitter: fixos/distribuídos; verifique os line e per-try timeout.
Temporizações/quebras: conexões half-open, RST, reset fluxo H2, 503/Retry-After.
Perdas/duplicados em lote: para gRPC/striptease.
Ferramentas: Toxiproxy, MockServer, xk6-disruptor, netem em CI.

toxiproxy-cli toxic add psp --type latency --latency 300 --jitter 100

9) Dados, segredos e determinismo

Redact e sintético: nada de PII em ficstures; dinheiro - decimal/formatação rigorosa.
Fixação do tempo: fake clock; «Ontem/hoje» - controle.
Idempotidade: A mesma 'Idempotency-Key' → a mesma resposta.
Geradores: fábricas/bilders de dados com valores transparentes (e. g., `test_user_001`).
Versionize ficstures (tags), não guarde as respostas «retiradas» sem mediação.

10) CI/CD e ambiente

Matriz: unit (in-processo fakes) → componente (virtualização local) → integração (mínimo de mocos, Testcontainers).
Artefatos: ficheiros pact, ecrãs de ecrã, logs de servidores Mc, PCAP em baixas.
Paralelidade: portas/prefixos de chave exclusivos; Isolamento dos contêineres.
Gate: contrato verde (CDC verify), especificação valida (lint), negativado.

11) Antipattern

Os moki «copiam» defeitos do serviço real → falsas certezas. Tratado com contratos e recorde periódico/verify.
Os Macromocks de todo o mundo em cada teste → fragilidade, caro maintenance. Faça portos finos e LCA.
Moki em E2E, onde você precisa de integração real (especialmente pagamentos/webhooks com HMAC/mTLS).
Flacks devido ao tempo/random/corridas de rede → use fake clock, sedimentos determinados.
Segredos em ficstouts/repositório. Segredos só através do cofre secreto da CI.

12) Especificidades do iGaming/Finanças

Pagamentos/conclusões: Os mooks devem suportar «Idempotency-Key», «Retry-After», HMAC/mTLS, códigos de sanções e respostas «longas».
Bónus-lógica/antifrod: cenários de velocidade/429, ATC/challenge, soluções de risco 'allow/deny/challenge' com TTL.
KYC/AML: Respostas sandbox por nível KYC, negativos (mismatch, documentos inválidos), webhooks anti-replay ('X-Timestamp' janela).
Jurisdição/Tenentes: títulos obrigatórios 'X-Tenant/X-Region', perfis de resposta diferentes.

13) Mini-receitas (espartilho)

Repetição de pagamento: WireMock «Cenários» - o primeiro «201», o segundo «409 duplicate».
PSP lento: MockServer 'responseDelay' + verificação para-try timeout no cliente.
Webhooks: servidor HTTP local + verificação de assinatura HMAC; Uma repetição em 5 segundos não cria uma tiragem.
Kafka-duplicados: Publique a mesma mensagem duas vezes; O hendler tem de ser idepotente.
Estatais GRPC: matrix testes por 'codes' (InvalidArgument, DeadlineExceeded, ResourceExhausted).

14) Folha de cheque pró-prontidão

• Portas/adaptadores selecionados; As integrações estão escondidas atrás das interfaces.
• Para HTTP/gRPC - Há contracto-aware de manadas (Pact/OpenAPI/Proto) com negativos.
• Para corretores - Testcontainers + Registry; testes de duplicação/ordem/mensagens grandes.
• Caos: atrasos, temporizações, reset, 429/503 com 'Retry-After'; a rede é emulada (Toxiproxy/netem).
• Ficturas sem PII; fake clock; a idimpotência está a ser assinada.
• Matriz CI: unit → component → integration; artefatos de logs/contratos são mantidos.
• Caixas de areia dos provedores: chaves separadas, endpointos configurados e runbook.
• Record/Replay é atualizado de acordo com o cronograma, e os trens são editados.
• Métricas flaky e duração dos testes sob controle; Alertas com altura.

15) TL; DR

Isole as integrações através de portas finas e use a ferramenta correta para a tarefa: stubs para maletas simples, mocks para verificação de interações, fakes para comportamento realista, serviço de virtualização e chaos para erros de rede e raros. Façam um contrato-consciente (Pact/OpenAPI/Proto), mantenham as ficturas minadas e sem PII, simulem atrasos/temporizações/429/5xx. Em CI, construa a pirâmide: unit → component → integration; bloqueie o lançamento com contratos vermelhos. Para os caminhos de pagamento/CUS, leve em consideração HMAC/mTLS, idempotidade e cenários negativos.