Seu código depende de um serviço que você não controla. Um gateway de pagamento, uma API parceira, um mainframe legado, um microsserviço de outra equipe. Essa dependência está em manutenção, limita as execuções de seus testes, cobra por chamada ou retorna dados inconsistentes. Assim, seu desenvolvimento estagna e seu pipeline de CI fica vermelho por motivos que nada têm a ver com o seu código.
A virtualização de serviços resolve isso. Você substitui a dependência real por um substituto que se comporta como ela, para que possa desenvolver e testar contra algo que você controla totalmente. Este guia explica o que é virtualização de serviços, como ela difere de mocking e stubbing, por que as equipes a utilizam e quais ferramentas realizam o trabalho, com comandos reais para WireMock, Hoverfly, Mountebank, as opções corporativas e o servidor mock do Apidog para virtualização de contrato de API.
O que é virtualização de serviços
A virtualização de serviços simula o comportamento de uma dependência que você não controla, para que sua aplicação possa se comunicar com a simulação em vez da coisa real.
A palavra “comportamento” tem peso aqui. Um bom serviço virtual não retorna apenas um payload fixo. Ele corresponde a detalhes da requisição, retorna respostas diferentes para entradas diferentes, mantém o estado entre chamadas, injeta latência e falhas, e fala o mesmo protocolo que o sistema real. O objetivo é um substituto realista o suficiente para que seu código não consiga perceber a diferença durante o desenvolvimento e os testes.
O termo “virtualização de API” significa a mesma coisa quando a dependência é uma API HTTP, e “simulador de API” é a ferramenta que produz o endpoint virtual. Trate ambos como sinônimos para a fatia da virtualização de serviços focada em API.
Virtualização de serviços vs. mocking vs. stubbing
Esses três termos se sobrepõem, e as pessoas os usam livremente. Aqui está uma maneira prática de separá-los.
Um stub retorna uma resposta codificada. Ele ignora a requisição e sempre responde da mesma maneira. Se seu teste chama GET /user/42 e o stub está configurado para retornar um objeto de usuário fixo, ele retorna o mesmo objeto, independentemente do ID que você enviar. Stubs são a forma mais simples e vivem dentro do seu código de teste.
Um mock é um stub que também verifica interações. Ele registra como foi chamado (quais métodos, quais argumentos, quantas vezes) para que seu teste possa afirmar que seu código usou a dependência corretamente. Mocks são uma ferramenta de teste de unidade. Eles geralmente são executados em processo, na mesma linguagem do seu código. Nossa explicação sobre stubbing vs. mocking de API aprofunda essa distinção.
A virtualização de serviços opera sobre a rede, não no seu código. Ela levanta um serviço em execução em uma porta de rede real que fala um protocolo real. Sua aplicação se conecta a ele da mesma forma que se conectaria à produção, alterando uma URL base ou uma configuração de proxy. Um serviço virtual pode ser com estado (stateful), pode corresponder a condições de requisição complexas e pode simular comportamento em nível de protocolo, como códigos de status HTTP, cabeçalhos, streaming e falhas de conexão.
A linha entre “mock” e “virtualização de serviços” é borrada no uso diário. Muitas equipes chamam um servidor mock HTTP em execução de “um mock” mesmo quando ele faz virtualização completa. Isso é aceitável. A distinção que importa: você está substituindo um objeto dentro do seu processo (mocking/stubbing) ou levantando um serviço em rede ao qual sua aplicação se conecta (virtualização)? Consulte API mocking: tudo o que você precisa saber para o lado do mock.
Por que as equipes usam virtualização de serviços
Três problemas impulsionam a maior parte da adoção.
A dependência não está pronta. As equipes de frontend e backend trabalham em paralelo, e o frontend precisa de uma API funcional antes que o backend a entregue. Um serviço virtual construído a partir do contrato da API permite que o frontend construa com respostas realistas hoje. Ninguém espera.
A dependência é cara ou tem limite de taxa. APIs de terceiros frequentemente cobram por chamada ou limitam agressivamente, então executar uma suíte de testes completa contra um ambiente de sandbox ativo consome cota e dinheiro. Um serviço virtual é gratuito para ser acessado, então seu CI pode executar milhares de cenários por dia.
A dependência é inconsistente ou difícil de controlar. Você não consegue facilmente fazer um provedor de pagamento real retornar um erro específico, exceder o tempo limite ou enviar uma resposta malformada. Um serviço virtual produz qualquer um desses sob demanda, que é como você testa os caminhos de erro que causam falhas em produção.
Há também um benefício de controle. Dependências reais têm dados que mudam sem o seu controle. Um serviço virtual oferece um estado fixo e conhecido, para que seus testes sejam determinísticos. Um build verde significa que seu código funciona, não que um sistema remoto se comportou bem hoje.
Como a virtualização de serviços funciona
A maioria das ferramentas segue um de dois padrões.
Gravação e reprodução. Você aponta a ferramenta para o serviço real como um proxy, executa o tráfego real através dele uma vez, e ele captura os pares de requisição/resposta. Mais tarde, ele reproduz essas gravações em vez de chamar o serviço real. Isso é rápido porque você não escreve as respostas manualmente. Os modos de captura do Hoverfly e de gravação do WireMock funcionam dessa maneira.
Orientado por especificação. Você define o serviço virtual a partir de um contrato de API ou manualmente: declara quais requisições correspondem a quais respostas, adiciona valores dinâmicos e configura o comportamento com estado (stateful). Dá mais trabalho inicialmente, mas oferece controle total e funciona mesmo quando o serviço real ainda não existe.
De qualquer forma, o mecanismo central é a correspondência de requisições. Quando uma requisição chega, a ferramenta a verifica em relação a um conjunto de regras (caminho, método, parâmetros de consulta, cabeçalhos, corpo) e retorna a resposta vinculada à primeira correspondência. Ferramentas melhores adicionam templating, para que uma resposta possa ecoar partes da requisição ou gerar novos valores a cada chamada. É assim que um serviço virtual parece vivo em vez de estático.
As ferramentas
Aqui estão as principais opções, desde ferramentas de código aberto focadas em HTTP até suítes corporativas robustas. Verifique as versões e recursos atuais nas documentações de cada projeto antes de se comprometer, já que eles evoluem rapidamente.
WireMock
WireMock é uma ferramenta de mocking de API e virtualização de serviços de código aberto para HTTP. Ele pode ser executado como um processo independente, embutido em testes JVM ou em um contêiner. Você define os mapeamentos de stub como JSON, e o WireMock corresponde as requisições de entrada a eles. Ele suporta gravação e reprodução contra um serviço real, templating de resposta, cenários com estado (stateful), injeção de falhas e atrasos simulados.
Execute o JAR autônomo:
java -jar wiremock-standalone-3.13.2.jar --port 8080
Em seguida, registre um stub através de sua API administrativa:
curl -X POST http://localhost:8080/__admin/mappings \
-H "Content-Type: application/json" \
-d '{
"request": {
"method": "GET",
"url": "/user/42"
},
"response": {
"status": 200,
"headers": { "Content-Type": "application/json" },
"jsonBody": { "id": 42, "name": "Ada Lovelace" }
}
}'
WireMock é mais forte quando suas dependências são HTTP e você deseja controle granular em configurações JVM ou containerizadas. Há uma versão comercial hospedada (WireMock Cloud) se você quiser uma opção gerenciada.
Hoverfly
Hoverfly é uma ferramenta de virtualização de serviços leve e de código aberto escrita em Go. Ela funciona como um proxy: você direciona o tráfego de saída da sua aplicação através do Hoverfly, e ele ou grava respostas reais ou reproduz as simuladas. Ele opera em vários modos, incluindo captura, simulação, espionagem, modificação, síntese e comparação (diff).
Um fluxo básico de captura e reprodução usando seu comando hoverctl:
hoverctl start
hoverctl mode capture
curl --proxy http://localhost:8500 https://api.example.com/user/42
hoverctl export simulation.json
hoverctl mode simulate
A API de administração do Hoverfly é executada na porta 8888 e seu proxy na porta 8500 por padrão. O modelo de proxy de gravação e reprodução o torna uma boa opção quando você deseja virtualizar o tráfego existente rapidamente, em vez de escrever cada resposta manualmente. Há também um Hoverfly Cloud hospedado.
Mountebank
Mountebank é uma ferramenta de código aberto construída em torno de “impostores”. Um impostor é um único serviço virtual que escuta em uma porta e fala um protocolo. Além de HTTP e HTTPS, Mountebank também lida com TCP e SMTP, o que é útil quando sua dependência não é uma API REST simples. Você o controla inteiramente através de um plano de controle REST na porta 2525.
Instale e inicie-o:
npm install -g mountebank
mb
Em seguida, crie um impostor enviando JSON via POST para a porta de controle:
curl -X POST http://localhost:2525/imposters \
-H "Content-Type: application/json" \
-d '{
"port": 4545,
"protocol": "http",
"stubs": [{
"predicates": [{ "equals": { "method": "GET", "path": "/user/42" } }],
"responses": [{ "is": { "statusCode": 200, "body": "{\"id\":42,\"name\":\"Ada Lovelace\"}" } }]
}]
}'
Os predicados decidem qual requisição corresponde; as respostas definem o que retorna. O alcance multiprotocolo do Mountebank é seu diferencial entre as opções de código aberto.
Parasoft Virtualize e Broadcom Service Virtualization
Para grandes empresas, os pesos pesados são Parasoft Virtualize e Broadcom Service Virtualization (parte da suíte DevTest). São plataformas comerciais construídas para equipes que precisam simular muitos protocolos e formatos de mensagem além do HTTP, conectar serviços virtuais a fontes de dados reais e gerenciar a virtualização em muitos ambientes de forma centralizada.
Parasoft Virtualize anuncia suporte para uma ampla gama de protocolos e formatos de mensagem padrão da indústria, além de serviços virtuais orientados por dados alimentados por fontes de dados externas. A oferta da Broadcom visa cenários corporativos semelhantes com ambientes virtualizados para desenvolvimento e teste paralelos. Ambos acarretam licenciamento empresarial e sobrecarga de configuração, por isso se encaixam quando você está virtualizando protocolos legados (mainframe, MQ, mensagens de tamanho fixo) em escala, em vez de um punhado de endpoints REST. Se suas dependências são APIs HTTP comuns, as ferramentas de código aberto acima ou uma plataforma de API o atendem por uma fração do custo. Confirme as listas de protocolos e preços atuais com cada fornecedor.
Apidog: virtualização de serviços leve para contratos de API
Se a dependência que você precisa virtualizar é uma API HTTP definida por um contrato, o Apidog cobre essa fatia sem uma ferramenta separada. Quando você projeta ou importa uma API, o Apidog levanta um servidor mock para ela automaticamente. Seu frontend ou suíte de testes obtém um endpoint funcional a partir apenas do esquema, antes que qualquer código de backend exista.
O que torna isso mais próximo da virtualização do que um stub simples é que o mock do Apidog é sensível ao esquema (schema-aware) e dinâmico. Seu Smart Mock lê seu JSON Schema e gera respostas que respeitam todas as restrições (tipos, formatos, enums, campos obrigatórios). Ele também corresponde nomes de campos a regras incorporadas, de modo que um campo chamado email retorna um e-mail válido e um campo chamado city retorna um nome de cidade, em vez de lixo de preenchimento. Para um controle mais refinado, valores dinâmicos baseados no Faker.js geram dados realistas a cada chamada, e você pode fixar valores onde precisa de determinismo.
Você também pode escrever regras de mock personalizadas que retornam respostas diferentes com base nos parâmetros da requisição, que é o comportamento de correspondência de requisições que separa a virtualização de um stub fixo. O servidor mock é executado na GUI ou sem interface (headless), então ele se adapta tanto ao desenvolvimento local quanto ao CI. Consulte como simular uma API em um minuto para um passo a passo.
Onde o Apidog se encaixa: virtualização de serviços de contrato de API para HTTP/REST e similares. Onde ele não se encaixa: não é uma ferramenta de gravação e reprodução baseada em proxy para protocolos legados arbitrários, e não é um gerador de carga. Para esses casos, as ferramentas acima são a escolha certa. Para uma comparação mais ampla ferramenta por ferramenta, consulte ferramentas online de mocking de API comparadas e as 10 melhores ferramentas de mocking de API.
Como começar
Combine a ferramenta com a dependência, não o contrário.
- Identifique o protocolo. HTTP/REST puro? Quase tudo aqui funciona, e uma plataforma de API é a que oferece menor atrito. Precisa de TCP ou SMTP? Mountebank. Protocolos empresariais legados em escala? Parasoft ou Broadcom.
- Decida entre gravar ou especificar. Se o serviço real existe e você pode rotear o tráfego através dele, a gravação e reprodução (Hoverfly, modo de gravação do WireMock) é a mais rápida. Se ainda não existe, crie o serviço virtual a partir do contrato da API (Apidog, stubs do WireMock, imposters do Mountebank).
- Aponte seu aplicativo para ele. Altere uma URL base ou configuração de proxy em seu ambiente de teste ou desenvolvimento, e mantenha isso por trás de uma configuração para que a troca entre virtual e real seja uma única variável.
- Adicione os casos de falha. O benefício é testar caminhos de erro, então adicione respostas para 4xx e 5xx, timeouts e corpos malformados. Essa é a parte que as dependências reais não permitirão que você ensaie.
- Execute-o no CI. Um serviço virtual que só é executado no seu laptop ajuda você, mas não o build. Coloque-o no pipeline para que verde signifique verde. Se você precisa de um mock que funcione sem interface (headless) no CI sem uma GUI, consulte ferramentas de mock de API sem interface.
Para a troca entre dependências virtuais e reais em geral, servidor mock vs. servidor real descreve quando usar cada um.
FAQ
A virtualização de serviços é o mesmo que mocking? Não exatamente. Mocking geralmente substitui um objeto dentro do seu processo para testes de unidade e verifica como ele foi chamado. A virtualização de serviços levanta um serviço em execução em uma porta de rede à qual sua aplicação se conecta por um protocolo real. As pessoas chamam serviços virtuais HTTP de “mocks” no uso casual, o que é aceitável, mas a distinção técnica é objeto em processo versus serviço em rede.
Quando devo usar um serviço virtual em vez de um ambiente de teste real? Use a virtualização quando a dependência real estiver indisponível, tiver limite de taxa, for cara ou difícil de controlar. Ela oferece respostas determinísticas, gratuitas, sempre disponíveis e permite simular erros que você não consegue acionar no sistema real. Mantenha um conjunto menor de testes contra o serviço real para confiança final na integração.
Um serviço virtual pode ser com estado (stateful)? Sim. Ferramentas como WireMock e Mountebank suportam cenários com estado onde a resposta muda com base em requisições anteriores, por exemplo, retornando um carrinho vazio e, em seguida, um carrinho com itens após um POST. Isso é importante quando você está simulando fluxos de trabalho em vez de chamadas únicas.
Preciso de uma ferramenta empresarial paga? Somente se você estiver virtualizando muitos protocolos não HTTP ou gerenciando a virtualização em uma grande organização. Para APIs HTTP comuns, ferramentas de código aberto (WireMock, Hoverfly, Mountebank) ou um servidor mock de plataforma de API dão conta do recado sem licenciamento empresarial.
Qual é a maneira mais rápida de virtualizar uma API HTTP a partir de sua especificação? Importe a definição da API para uma ferramenta que gera um mock a partir do esquema. O Apidog faz isso automaticamente: importe sua especificação OpenAPI e você obtém um servidor mock sensível ao esquema (schema-aware) com dados dinâmicos realistas, sem necessidade de escrever respostas. A partir daí, você adiciona regras personalizadas para as condições específicas de requisição/resposta que seus testes precisam.