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.

Experimente o Apidog hoje

💡 Apidog é uma plataforma de desenvolvimento de API gratuita e completa com Smart Mock integrado que cria endpoints mock instantâneos a partir das suas definições de API, sem a necessidade de um processo Java local. Experimente o Apidog gratuitamente, sem necessidade de cartão de crédito.

Introdução

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

O serviço de mock do SoapUI está disponível desde as primeiras versões. Ele executa um servidor HTTP local que responde conforme as regras configuradas. O problema é que esse processo local causa atrito: encerra ao fechar o SoapUI, não pode ser acessado facilmente por outros membros da equipe e a configuração é trabalhosa.

Veja como funcionam os serviços de mock do SoapUI, como configurá-los, principais problemas enfrentados por equipes e como o Apidog resolve esses pontos.

Como os serviços de mock do SoapUI funcionam

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

1. Escuta em uma porta local configurada (ex: 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 SOAP, o SoapUI pode gerar respostas mock automaticamente a partir do WSDL, criando stubs para cada operação.

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

Para interface SOAP

1. No projeto SoapUI, clique com o botão direito em uma interface SOAP na árvore de projeto.
2. Selecione "Gerar MockService".
3. Configure:
   • Nome do serviço (ex: "OrderService Mock")
   • Número da porta (default: 8088; altere se necessário)
   • Caminho (ex: /orders)
4. Clique em OK. Será criado um nó MockService na árvore do projeto.
5. Expanda o nó MockService. Cada operação SOAP terá uma MockOperation.
6. Clique duas vezes numa MockOperation para abrir o editor de resposta mock.
7. Edite o XML da resposta SOAP conforme desejado.
8. Clique no botão verde de reprodução para iniciar o servidor local.

Seu mock estará disponível em http://localhost:8088/orders. Aponte seu código cliente para essa URL.

Para interface REST

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

Configurando o despacho

Por padrão, o serviço retorna a primeira resposta mock encontrada. Para respostas variadas conforme a entrada, configure um "script de despacho" (Groovy) ou use o tipo de despacho "SEQUENCE".

• Despacho em sequência: retorna respostas em ordem fixa nas chamadas.
• Despacho SCRIPT: um script Groovy inspeciona a requisição e retorna o nome da resposta.

Exemplo de script de despacho:

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

Crie múltiplas respostas mock nomeadas ("OrderFoundResponse", "OrderNotFoundResponse"), e o script define qual será retornada.

Problemas comuns com serviços de mock do SoapUI

1. Mock para quando o SoapUI é fechado

O serviço de mock roda como parte do processo JVM do SoapUI. Ao fechar o SoapUI, o mock para — colegas de equipe perdem o acesso.

Soluções alternativas:

• Manter o SoapUI aberto em uma máquina/VM dedicada
• Usar o mockservicerunner em linha de comando: mockservicerunner.sh -p 8088 -s "OrderService Mock" project.xml
• Usar uma máquina compartilhada persistente

Todas exigem Java e infraestrutura adicional.

2. Compartilhando o mock com a equipe

Mocks em localhost:8088 só estão acessíveis localmente. Para compartilhamento, é necessário configurar acesso de rede à máquina, firewall/VPN, ou rodar o mock em um servidor compartilhado.

3. Scripts de despacho quebram com XML complexo

Scripts de despacho em Groovy fazem match por string no XML bruto. Com namespaces diferentes, o mesmo valor pode aparecer de formas distintas, quebrando scripts simples. É necessário usar parsing XML e GroovyUtils, aumentando a complexidade.

4. O estado não persiste entre chamadas

Mocks SoapUI são stateless por padrão. Para simular fluxos como POST (criar) + GET (buscar), scripts Groovy devem armazenar estado em variáveis compartilhadas, o que é frágil.

5. SSL para serviços de mock

Para HTTPS, é preciso configurar keystore, definir SSL no SoapUI e distribuir certificados — muito mais trabalho do que mocks só HTTP.

Apidog Smart Mock: como se compara

No Apidog, o mock é gerado a partir do design da API — sem processos para rodar.

Ao definir um endpoint de API no Apidog (método, caminho, esquema de requisição/resposta), é criado automaticamente um endpoint mock na nuvem.

A URL do mock será similar a:

https://{seu-projeto}.mock.apidog.io/orders/{id}

Vantagens:

• Sempre disponível (sem servidor local)
• Acessível para todos da equipe com acesso ao projeto
• Gera respostas a partir do schema definido

Como o Apidog gera respostas mock

O Apidog lê o schema de resposta (JSON Schema/OpenAPI) e gera dados falsos realistas.

Exemplo:

• orderId do tipo string (formato UUID) → retorna um UUID aleatório
• amount do tipo number (0 a 10000) → retorna número nesse range

Você pode configurar regras de mock customizadas para campos específicos. Exemplo: fixar orderId como "test-123".

Endpoints SOAP no Apidog Mock

O Smart Mock do Apidog é otimizado para REST/JSON. Para SOAP:

• Crie uma requisição no Apidog
• Configure uma resposta personalizada com envelope SOAP
• Use o mock server do Apidog para retornar essa resposta

Não há geração automática baseada em WSDL, mas é suficiente para mocks SOAP simples sem rodar Java.

Mocking com estado

O Apidog permite scripts de resposta customizados (JavaScript) para simular comportamento com estado. Inspecione o body da requisição e retorne diferentes respostas, similar ao Groovy do SoapUI, mas em JavaScript.

Comparação lado a lado

Recurso	Mock do SoapUI	Apidog Smart Mock (link)
Requer Java	Sim	Não
Sempre ativo	Apenas via linha de comando	Sim (nuvem)
Acessível pela equipe	Configuração manual de rede	Sim, via URL compartilhada
Geração automática de WSDL	Sim	Não
Baseado em esquema REST	Não	Sim
Respostas dinâmicas	Despacho Groovy	Scripts de mock JavaScript
Suporte HTTPS	Configuração manual de keystore	Integrado
Mocking com estado	Via variáveis Groovy	Via scripts JavaScript
Grátis	Sim	Sim

Quando usar cada um

Use o SoapUI Mock Service quando:

• Precisa simular SOAP via WSDL com geração automática de stubs
• Equipe trabalha offline ou em ambientes restritos
• Já utiliza fortemente o SoapUI e não quer mudar de ferramenta

Use o Apidog Smart Mock quando:

• Simula endpoints REST e precisa compartilhar mocks sem configurar rede
• Precisa de mocks sempre disponíveis, sem processos locais
• Está iniciando um projeto novo e já define contrato de API
• Quer evitar manter ambiente Java apenas para mocks

FAQ

Posso executar mocks do SoapUI sem interface gráfica?

Sim, use mockservicerunner.sh (Linux/macOS) ou mockservicerunner.bat (Windows) com o caminho do projeto e nome do serviço. Java ainda é necessário, mas não a interface gráfica.

O Apidog suporta mocks SOAP?

Parcialmente. Permite configurar respostas customizadas com XML SOAP, mas não gera respostas stub automáticas via WSDL. Para SOAP conhecido, a configuração manual é viável.

Mocks do SoapUI simulam respostas lentas?

Sim. Configure "Delay" (ms) na resposta mock. O Apidog também suporta atraso configurável para simular rede lenta.

Quantas requisições de mock o Apidog suporta?

O mock server em nuvem do Apidog cobre cargas típicas de desenvolvimento/teste. Para cargas de performance elevadas, considere servidor mock dedicado.

Se dois membros da equipe precisam de mocks diferentes para o mesmo endpoint?

No SoapUI, cada um executa seu mock local. No Apidog, crie múltiplos ambientes ou use parâmetros de consulta para cenários distintos. O recurso "Mock expects" permite associar condições de requisição a respostas diferentes.

O Apidog exige API totalmente definida?

Ter um schema de resposta ajuda a gerar dados realistas, mas é possível criar respostas mock manuais sem schema completo. Basta definir o endpoint e o corpo da resposta.

O SoapUI é funcional, mas depende de processo Java local. Para equipes modernas que precisam de mocks persistentes e compartilhados, o Apidog em nuvem elimina a sobrecarga de coordenação.

---