Serviço Mock SoapUI: Guia de Configuração e Alternativa Moderna

TL;DR

Serviços de mock do SoapUI simulam endpoints SOAP ou REST localmente, mas exigem um processo Java em execução, configuração manual de despacho e não podem ser compartilhados entre uma equipe sem uma máquina compartilhada. O Smart Mock do Apidog gera respostas mock a partir do seu esquema de API, é executado na nuvem e é compartilhado automaticamente com sua equipe.

Introdução

Serviços de mock resolvem um problema comum no desenvolvimento de API: você quer testar como seu código cliente lida com um serviço antes que ele esteja pronto, ou você quer testar casos extremos (erros, respostas lentas) sem causá-los em um sistema real.

O recurso de serviço de mock do SoapUI está disponível desde as primeiras versões e funciona. Ele executa um servidor HTTP local que responde a requisições de acordo com as regras que você configura. O problema é que esse processo local cria atrito: ele morre quando você fecha o SoapUI, outros membros da equipe não conseguem acessá-lo sem truques de rede, e a interface de configuração é complicada.

Este guia aborda como os serviços de mock do SoapUI funcionam, como configurá-los, os problemas comuns que as equipes enfrentam e como a abordagem do Apidog se compara.

Como os serviços de mock do SoapUI funcionam

O SoapUI cria serviços de mock a partir de interfaces SOAP ou REST existentes em seu projeto. O serviço de mock:

1. Escuta em uma porta local que você configura (por exemplo, http://localhost:8088/MockService)
2. Intercepta requisições de entrada
3. Associa a requisição a uma "resposta mock" usando lógica de despacho
4. Retorna a resposta configurada

Para serviços SOAP, o SoapUI pode gerar automaticamente respostas mock a partir do seu WSDL, criando respostas stub para cada operação. Isso é útil para simular um serviço antes que ele exista ou antes que você tenha acesso ao endpoint real.

Configurando um serviço de mock do SoapUI (passo a passo)

Para uma interface SOAP

1. No seu projeto SoapUI, clique com o botão direito em uma interface SOAP na árvore do projeto.
2. Selecione "Gerar MockService".
3. Na caixa de diálogo, configure:

• Nome do serviço (por exemplo, "OrderService Mock")
• Número da porta (o padrão é 8088; altere se a porta estiver em uso)
• Caminho (por exemplo, /orders)

1. Clique em OK. O SoapUI cria um nó MockService na árvore do seu projeto.
2. Expanda o nó MockService. Você verá uma "MockOperation" para cada operação SOAP na interface.
3. Clique duas vezes em uma MockOperation para abrir o editor de resposta mock.
4. Edite o XML da resposta SOAP para retornar os valores que você deseja simular.
5. Clique no botão verde de reprodução no editor do MockService para iniciar o servidor local.

Seu mock agora está em execução em http://localhost:8088/orders. Aponte seu código cliente para esta URL.

Para uma interface REST

1. Clique com o botão direito em uma interface ou recurso REST na árvore do projeto.
2. Selecione "Adicionar ao MockService" ou "Gerar MockService".
3. Configure a porta e o caminho como acima.
4. Para cada recurso/método, configure o corpo da resposta mock e o código de status.
5. Inicie o serviço de mock.

Configurando o despacho

Por padrão, o serviço de mock do SoapUI retorna a primeira resposta mock que encontra. Se você deseja respostas diferentes para entradas diferentes, configure um "script de despacho" (Groovy) ou use o tipo de despacho "SEQUENCE".

Despacho em sequência: Retorna respostas em uma ordem fixa em chamadas sucessivas. A Chamada 1 recebe a resposta A, a Chamada 2 recebe a resposta B.

Despacho SCRIPT: Um script Groovy inspeciona a requisição e retorna um nome de resposta baseado na lógica.

Exemplo de script de despacho:

def request = mockRequest.getRequestContent()
if (request.contains("orderId>12345")) {
  return "OrderFoundResponse"
} else {
  return "OrderNotFoundResponse"
}

Você cria várias respostas mock nomeadas (por exemplo, "OrderFoundResponse", "OrderNotFoundResponse") e o script de despacho seleciona qual retornar com base no conteúdo da requisição de entrada.

Problemas comuns com serviços de mock do SoapUI

Problema 1: O mock para quando o SoapUI é fechado

O serviço de mock do SoapUI é executado como parte do processo JVM do SoapUI. Quando você fecha o SoapUI, o mock para. Colegas de equipe que estão usando o mock o perdem.

Soluções alternativas:

• Mantenha o SoapUI aberto em uma máquina ou VM dedicada
• Use a opção de servidor de mock de linha de comando do SoapUI: mockservicerunner.sh -p 8088 -s "OrderService Mock" project.xml
• Use uma máquina compartilhada persistente que sempre executa o mock

Nenhuma dessas soluções é elegante. A opção de linha de comando ajuda, mas ainda exige uma máquina com SoapUI e Java instalados.

Problema 2: Compartilhando o mock com a equipe

Um mock em localhost:8088 é acessível apenas para a pessoa que o está executando. Para que os colegas de equipe acessem o mesmo mock, você precisa de acesso à rede dessa máquina (regras de firewall, configuração de VPN) ou para executar o mock em um servidor compartilhado.

Problema 3: Scripts de despacho quebram com XML complexo

Os scripts de despacho do SoapUI usam correspondência de strings Groovy no corpo XML bruto. Envelopes SOAP têm namespaces, e o mesmo valor lógico pode aparecer com diferentes prefixos de namespace, dependendo do cliente. Scripts que procuram strings literais como <orderId>12345</orderId> quebram quando o prefixo é diferente.

A correção exige análise de XML adequada no script de despacho usando a classe GroovyUtils do SoapUI, o que aumenta a complexidade.

Problema 4: O estado não persiste entre as chamadas

Os serviços de mock do SoapUI são stateless por padrão. Se você quiser simular um fluxo de trabalho de criar e depois ler (POST para criar, GET para recuperar), você precisa de um script de despacho Groovy que armazene o estado em uma variável compartilhada. Isso funciona, mas é frágil.

Problema 5: SSL para serviços de mock

Configurar HTTPS para um serviço de mock do SoapUI requer a configuração de um keystore, a configuração das definições SSL do SoapUI e o apontamento dos clientes para o certificado correto. Isso é consideravelmente mais envolvido do que mocks somente HTTP.

Apidog Smart Mock: como se compara

A abordagem de mock do Apidog começa pelo design da API, não por um processo em execução.

Quando você define um endpoint de API no Apidog (método, caminho, esquema de requisição, esquema de resposta), o Apidog gera automaticamente um endpoint de mock na nuvem. Nenhuma configuração é necessária.

A URL do mock se parece com: https://{seu-projeto}.mock.apidog.io/orders/{id}

Esta URL é:

• Sempre em execução (nenhum processo local para iniciar ou parar)
• Acessível a todos os membros da equipe com acesso ao projeto
• Gerando respostas a partir do esquema que você definiu

Como o Apidog gera respostas mock

O Apidog lê seu esquema de resposta (JSON Schema ou definição de resposta OpenAPI) e gera dados falsos realistas. Um esquema que diz que `orderId` é uma `string` no formato UUID retorna um UUID aleatório. Um esquema que diz que `amount` é um `number` entre 0 e 10000 retorna um número nesse intervalo.

Você também pode configurar regras de mock personalizadas para campos específicos. Defina `orderId` para sempre retornar `"test-123"` quando precisar de um valor previsível.

Endpoints SOAP no Apidog Mock

O Smart Mock do Apidog é projetado para endpoints REST com respostas JSON. Para endpoints SOAP, a configuração do mock é manual: você cria uma requisição no Apidog, configura uma resposta personalizada com um envelope SOAP e usa o servidor de mock do Apidog para retorná-la.

Isso é menos automatizado do que a geração de mock baseada em WSDL do SoapUI, mas funciona para equipes que precisam de um mock SOAP simples sem executar um processo Java local.

Mocking com estado

O Apidog suporta scripts de resposta personalizados para comportamento de mock com estado. Você pode inspecionar o corpo da requisição em um script de mock JavaScript e retornar diferentes respostas com base no conteúdo da requisição, semelhante aos scripts de despacho do SoapUI, mas em JavaScript.

Comparação lado a lado

Quando usar cada um

Use os serviços de mock do SoapUI quando:

• Você precisa simular um serviço SOAP baseado em WSDL e deseja stubs de resposta gerados automaticamente
• Sua equipe trabalha offline ou atrás de controles de rede rigorosos
• Você já está profundamente inserido no ecossistema SoapUI e não quer mudar de ferramentas

Use o Apidog Smart Mock quando:

• Sua equipe simula endpoints REST e precisa de acesso compartilhado sem configuração de rede
• Você quer servidores de mock que permaneçam em execução sem intervenção manual
• Você está iniciando um novo projeto e definindo o contrato da API antes da implementação
• Você quer evitar instalar e manter um ambiente Java para serviços de mock

FAQ

Posso executar serviços de mock do SoapUI sem interface gráfica (headless)?Sim. O SoapUI inclui mockservicerunner.sh (Linux/macOS) e mockservicerunner.bat (Windows). Execute-os com o caminho do arquivo do projeto e o nome do serviço. Você ainda precisa ter Java instalado, mas não precisa que a interface gráfica esteja aberta.

O Apidog suporta serviços de mock SOAP?Parcialmente. Você pode configurar respostas personalizadas com XML SOAP no servidor de mock do Apidog. Você não obtém a geração automática de respostas stub baseada em WSDL. Para equipes com interfaces SOAP bem compreendidas, a configuração manual é gerenciável.

Os serviços de mock do SoapUI podem simular respostas lentas?Sim. Na configuração da resposta mock, defina um valor de "Delay" em milissegundos. O Apidog também suporta configuração de atraso de resposta para simular condições de rede lentas.

Quantas requisições de mock o Apidog pode lidar?O servidor de mock em nuvem do Apidog lida com cargas típicas de desenvolvimento e teste. Para testes de desempenho de alto volume, uma ferramenta de servidor de mock dedicada pode ser mais apropriada.

O que acontece se dois membros da equipe precisarem de respostas mock diferentes para o mesmo endpoint?No SoapUI, cada pessoa executa seu próprio mock local e pode configurá-lo independentemente. No Apidog, você pode criar múltiplos ambientes ou usar parâmetros de consulta para selecionar diferentes cenários de resposta. O recurso "Mock expects" do Apidog permite que você associe condições de requisição específicas a respostas específicas.

O mock do Apidog exige que a API seja totalmente definida primeiro?Um esquema de resposta ajuda o Apidog a gerar dados realistas, mas você pode criar respostas mock manuais sem um esquema completo. Defina o endpoint, defina um corpo de resposta personalizado e o mock funciona.

O serviço de mock do SoapUI é funcional, mas está vinculado a um processo Java local. Para equipes modernas que precisam de mocks persistentes e compartilhados, a abordagem baseada em nuvem do Apidog remove a sobrecarga de coordenação.