Mockar um serviço que não controlas
O caso é sempre o mesmo: o teu fluxo passa por um serviço que não é teu, e não lhe consegues chegar. Não tens VPN hoje, está em baixo, é mantido por outra equipa, ou simplesmente ainda não existe. Um mock desbloqueia a tarde — e é também a forma mais fácil de passares uma semana a testar contra uma mentira.
Primeiro: é um mock que precisas?
A pergunta que decide não é «consigo chegar a esse serviço?», mas «estou a testar a resposta dele ou a atravessá-la?».
| Situação | O que usar | Porquê |
|---|---|---|
| Precisas que devolva algo para o teu fluxo continuar | Mock | O conteúdo dele não é o que verificas; é uma pré-condição |
| Estás a comprovar como o teu código reage ao que devolve | O serviço real | Um stub vai dizer-te que está tudo bem, e não vais saber |
| Persegues uma falha que só aparece contra o verdadeiro | O ambiente partilhado | A falha vive na diferença entre o stub e o original |
| É um teste de integração | Testcontainers ou um duplo no teste | O ciclo de vida é governado pelo teste, não por ti |
| O serviço ainda não existe | Mock a partir do contrato | É o caso em que o mock não pode mentir: é a única fonte |
O risco que ninguém conta: o stub fica quieto
Um mock congela um contrato. O serviço real continua a mudar, e o teu stub não dá por isso: campos novos que não devolves, um código de erro que agora significa outra coisa, um formato de data que mudou. O teu código passa em local e falha ao integrar, que é exatamente o problema que o mock prometia evitar.
Duas coisas reduzem-no muito, e nenhuma delas é «ter cuidado»:
- Gera o stub a partir do contrato, não de memória. Se houver um OpenAPI, o esqueleto da resposta sai dali e regenera-se quando o contrato muda.
- Captura chamadas reais no dia em que tens acesso, e converte-as em stubs. Um exemplo capturado não inventa nada.
As quatro formas de o montar
| Forma | Custo de entrada | Onde se parte |
|---|---|---|
| Um servidor de stubs (WireMock, MockServer) no teu compose | Mais um contentor e os seus ficheiros de mapeamento | Continua a ser preciso redirecionar para lá o URL de quem chama, na configuração de um repositório alheio |
| Um serviço falso escrito à mão | Meia hora, e está feito | Torna-se um projeto que ninguém mantém e de que ninguém sabe de quem é |
| Intercetar no cliente HTTP do próprio serviço | Pouco, se o framework o permitir | É código de mentira dentro do teu repositório, e alguém o vai comitar |
| Um mock integrado no orquestrador | Instalar a ferramenta | Amarra o ambiente local a essa ferramenta |
Repara que três das quatro partilham o mesmo ponto de dor, e não é escrever o stub: é fazer com que quem chama vá ao stub. Isso significa mudar um URL na configuração de um repositório que muitas vezes não é teu, e desfazê-lo quando quiseres voltar ao serviço real.
Como o Aseptic o faz
O Aseptic trata «para onde chama esta dependência» como uma decisão de primeira classe,
não como uma edição de ficheiro. Para cada dependência escolhes entre três destinos —o
serviço local, o teu ambiente na nuvem ou um mock— e o motor reescreve o URL ao
arrancar, injetando-o como propriedade -D ou variável de ambiente.
Consequências práticas:
- O repositório não se toca. Nada para comitar, nada para reverter, nada para rever num pull request.
- Voltar atrás é mudar o destino, não desfazer uma edição. Podes ir e vir entre mock e serviço real várias vezes numa tarde.
- O resto do cenário fica a saber sozinho: a decisão toma-se uma vez e aplicam-na todos os que chamam esse serviço.
Os stubs definem-se no Mock Studio: capturar uma chamada e convertê-la em stub num clique, gerar o esqueleto da resposta a partir de um OpenAPI, e organizar variantes por serviço —a resposta feliz, a que dá 404, a que demora— com hot reload, sem reiniciar nada.
O que um mock não te vai dar
Convém dizê-lo aqui, porque é onde se perde tempo: se a falha que persegues vive no serviço real —um cabeçalho que a gateway acrescenta, um payload que ninguém documentou, o comportamento sob carga— o mock não a vai reproduzir, por definição. Aí o que é preciso é chegar ao ambiente partilhado, e se o teu sistema é demasiado grande para a tua máquina, a comparação com o Telepresence explica a outra abordagem.
Os passos concretos estão em mockar uma dependência, e se o que te bloqueia é ter de levantar demasiadas coisas, a página de levantar só parte do sistema.
Perguntas frequentes
Quando convém mockar um serviço e quando não?
Mocka-o quando a resposta dele não é o que estás a testar: precisas dela para o teu fluxo avançar, não para a verificar. Não o mockes quando o que queres comprovar é precisamente como o teu código reage ao que esse serviço devolve de verdade —aí um stub vai dizer-te que está tudo bem e não será verdade—.
Um mock não acaba por me mentir?
Pode, e é esse o seu risco real: o stub congela um contrato que do outro lado continua a mudar. Mitiga-se gerando-o a partir do OpenAPI do serviço em vez de à mão, e capturando chamadas reais quando conseguires chegar-lhe.
Como alterno entre o serviço real e o mock sem editar os meus repositórios?
Com o Aseptic é uma decisão por dependência: escolhes local, nuvem ou mock e o URL é reescrito ao arrancar, injetado como configuração. O ficheiro do repositório fica exatamente como está no git.
Preciso de escrever o stub à mão?
Não necessariamente. Pode gerar-se o esqueleto da resposta a partir de um OpenAPI, ou capturar uma chamada real na única vez em que tiveste acesso e convertê-la em stub num clique.