TL;DR
A migração do ReadyAPI para o Apidog é simples para conjuntos de testes que usam predominantemente REST. Exporte seu projeto ReadyAPI, converta o que puder via importação OpenAPI e recrie manualmente scripts Groovy em JavaScript. Casos de teste SOAP exigem o maior trabalho manual. Planeje uma migração faseada para manter a cobertura de testes contínua.
botão
Introdução
Migrar a infraestrutura de testes de API é uma daquelas tarefas que parece simples até você começar. Projetos ReadyAPI podem conter anos de casos de teste acumulados, scripts Groovy personalizados, arquivos de dados, ambientes e estruturas complexas de conjuntos de testes. Levar tudo isso para o Apidog exige entender o que é transferido automaticamente, o que precisa de conversão manual e o que você pode decidir deixar para trás.
Este guia detalha o processo de migração passo a passo. Ele aborda a exportação do seu projeto ReadyAPI, a análise do que você possui, a importação para o Apidog, o tratamento da conversão de Groovy para JavaScript, a configuração de CI/CD e a gestão do período de transição em que ambas as ferramentas funcionam em paralelo.
Passo 1: Audite seu projeto ReadyAPI antes de começar
Antes de exportar qualquer coisa, dedique um tempo para entender o que há em seu projeto ReadyAPI atual. Esta auditoria molda quanto tempo a migração levará e onde você deve concentrar seus esforços.
Abra seu projeto ReadyAPI e responda a estas perguntas:
Quantos conjuntos de testes, casos de teste e etapas de teste você tem? Abra o painel Navegador e conte. Um projeto com 50 casos de teste migra em horas. Um projeto com 500 leva dias.
Qual a porcentagem de casos de teste REST vs SOAP? Casos de teste REST migram de forma muito mais limpa. Casos de teste SOAP exigem mais trabalho manual, especialmente se usarem políticas WS-Security ou asserções complexas.
Quanto de scripting Groovy existe em seus casos de teste? Clique nos seus casos de teste e procure por etapas de Script. Conte quantos casos de teste possuem lógica Groovy personalizada. Cada script Groovy exige conversão manual para JavaScript.
Você está usando testes orientados a dados com etapas DataSource? O Apidog suporta testes orientados a dados com arquivos CSV e JSON, mas a configuração é diferente do padrão DataSource/DataSink do ReadyAPI.
Você usa muito as etapas Properties ou Property Transfer? Esses padrões funcionam de forma diferente no Apidog. Em vez disso, você usará variáveis e variáveis de ambiente.
Você está executando testes de carga através do LoadUI Pro? A integração do LoadUI Pro não é transferida para o Apidog. Você precisará configurar o k6 ou outra ferramenta de teste de carga separadamente para esses cenários.
Documente suas descobertas. Uma planilha com o nome do caso de teste, tipo (REST/SOAP), possui-Groovy (sim/não) e complexidade (simples/médio/complexo) lhe dará uma estimativa de migração antes de começar.
Passo 2: Exporte seu projeto ReadyAPI
O ReadyAPI armazena projetos como arquivos XML. Para exportar um projeto para análise:
- Abra o ReadyAPI e seu projeto.
- Vá em Arquivo > Salvar Como para salvar o projeto como um arquivo XML autônomo.
- Salve quaisquer arquivos de dados externos (CSV, Excel, dados de teste XML) que seus testes referenciam.
- Anote quaisquer configurações de ambiente que você tenha configurado na seção Ambientes.
O XML do projeto contém todos os conjuntos de testes, casos de teste, etapas de teste, scripts e configurações. É uma representação completa do seu projeto de teste.
Passo 3: Extraia suas definições de API
O caminho de migração mais limpo para APIs REST passa por uma especificação OpenAPI, não diretamente do XML do projeto ReadyAPI.
Opção A: Exportar do ReadyAPI. Se você tiver um serviço REST no ReadyAPI, clique com o botão direito nele no Navegador e procure por uma opção de exportação ou geração de definição de API. O ReadyAPI pode exportar especificações Swagger/OpenAPI a partir de definições de serviço.
Opção B: Use a especificação OpenAPI do seu backend. Se o seu serviço de backend já expõe uma especificação OpenAPI (em /openapi.json ou similar), faça o download diretamente. Isso lhe dará a definição mais precisa e atual.
Opção C: Extrair manualmente. Para APIs sem uma especificação existente, use suas requisições REST do ReadyAPI como fonte. Anote os endpoints, corpos de requisição, cabeçalhos e estruturas de resposta. Você os recriará no Apidog.
Passo 4: Importe para o Apidog
Com sua especificação OpenAPI pronta, importe-a para o Apidog.
- Abra o Apidog e crie um novo projeto.
- Vá em APIs > Importar e selecione seu formato (OpenAPI 3.0, Swagger 2.0, etc.).
- Faça o upload do arquivo de especificação ou cole a URL.
- O Apidog analisa a especificação e cria definições de API para todos os endpoints.
Após a importação, você terá uma definição de API estruturada com todos os endpoints, parâmetros, corpos de requisição e esquemas de resposta preenchidos. Esta é a base para seus casos de teste.
Se você tiver coleções Postman existentes (talvez migradas de uma ferramenta anterior), o Apidog também as importa via Arquivo > Importar > Postman.
Passo 5: Recrie casos de teste para endpoints REST
Para casos de teste REST, o processo de migração é:
- Abra um caso de teste REST do ReadyAPI.
- Identifique as requisições, asserções e quaisquer fontes de dados que ele utiliza.
- Crie um caso de teste correspondente no Apidog selecionando o endpoint da API e adicionando etapas de teste.
As asserções são traduzidas da seguinte forma:
- A asserção "Contém" (corpo contém string) torna-se uma asserção JavaScript:
pm.test('contains value', () => { pm.expect(pm.response.text()).to.include('expected string'); }); - Asserção de código de status:
pm.test('status 200', () => { pm.response.to.have.status(200); }); - Asserções JSONPath:
pm.test('field value', () => { pm.expect(pm.response.json().fieldName).to.equal('expected'); });;
Para testes GET e POST simples sem Groovy, esta migração é rápida. Um caso de teste simples com 5 a 10 asserções pode ser recriado em 15 a 30 minutos.
Passo 6: Converta scripts Groovy para JavaScript
Esta é a parte mais trabalhosa da migração para projetos com scripts personalizados significativos.
Padrões Groovy comuns e seus equivalentes em JavaScript:
Lendo um valor de resposta:
// Groovy (ReadyAPI)
def response = context.expand('${TestStep#Response}')
def json = new groovy.json.JsonSlurper().parseText(response)
def value = json.fieldName
// JavaScript (Apidog)
const response = pm.response.json();
const value = response.fieldName;
Definindo uma variável:
// Groovy
testRunner.testCase.setPropertyValue('myVariable', someValue)
// JavaScript
pm.variables.set('myVariable', someValue);
Asserções condicionais:
// Groovy
if (statusCode == 200) {
assert responseBody.contains("success")
}
// JavaScript
if (pm.response.code === 200) {
pm.test('response contains success', () => {
pm.expect(pm.response.text()).to.include('success');
});
}
Manipulação de data:
// Groovy
def now = new Date()
def formatted = now.format('yyyy-MM-dd')
// JavaScript
const now = new Date();
const formatted = now.toISOString().split('T')[0];
Para scripts Groovy complexos com importações de bibliotecas Java ou lógica intrincada, a conversão requer análise cuidadosa. Leia cada script, entenda o que ele faz e escreva o JavaScript equivalente. Não tente a tradução automática — a semântica é próxima o suficiente para enganar, mas diferente o bastante para causar bugs silenciosos.
Passo 7: Lide com casos de teste SOAP
Casos de teste SOAP são a parte mais desafiadora de qualquer migração do ReadyAPI. O Apidog não possui ferramentas SOAP dedicadas, portanto, estes exigem uma abordagem diferente.
Para serviços SOAP que também expõem uma interface REST (o que é cada vez mais comum), migre os testes para usar os endpoints REST e abandone a camada SOAP.
Para serviços SOAP sem alternativa REST, você tem duas opções:
Mantenha o ReadyAPI apenas para SOAP. Execute o ReadyAPI em paralelo para casos de teste SOAP e use o Apidog para REST. Este é um meio-termo prático que mantém a cobertura SOAP sem bloquear a migração REST.
Use o SoapUI Open Source. O SoapUI Open Source é gratuito e lida com testes SOAP. Ele não pode substituir todos os recursos do ReadyAPI, mas cobre testes funcionais SOAP básicos sem custo de licença.
Não apresse a migração SOAP. Casos de teste WS-Security, em particular, carregam um risco significativo se suas asserções não forem reproduzidas cuidadosamente.
Passo 8: Configure ambientes e variáveis
O recurso de Ambiente do ReadyAPI mapeia para o sistema de Ambiente do Apidog. Para cada ambiente ReadyAPI que você configurou:
- Crie um ambiente correspondente no Apidog (Configurações > Ambientes).
- Adicione as mesmas variáveis: URLs base, tokens de autenticação, cabeçalhos compartilhados, etc.
- Verifique se os casos de teste referenciam variáveis com a sintaxe correta do Apidog:
{{variableName}}em campos de URL e corpos de requisição.
Passo 9: Configure CI/CD
A configuração de CI do ReadyAPI geralmente envolve o comando testrunner nos agentes de build. O Apidog usa uma abordagem diferente.
Instale o CLI do Apidog no seu agente de CI:
npm install -g apidog-cli
Execute uma coleção de testes:
apidog run "path/to/collection.json" -e "environment-id"
Para GitHub Actions, uma etapa de workflow pode ser assim:
- name: Run API tests
run: apidog run collection.json --environment staging
Para Jenkins, adicione uma etapa de shell ao seu pipeline que chama o CLI do Apidog. Nenhuma instalação do ReadyAPI é necessária no agente de build.
Atualize seus arquivos de configuração de CI para usar o novo comando. Remova as referências ao testrunner do ReadyAPI assim que as execuções do Apidog forem validadas corretamente.
Passo 10: Execute ambas as ferramentas em paralelo durante a transição
Não faça a transição do ReadyAPI para o Apidog em um único dia. Execute ambas as ferramentas em paralelo por pelo menos um ciclo de lançamento.
Durante o período paralelo:
- Execute testes do ReadyAPI no CI como o portão de teste autoritário.
- Execute testes do Apidog em paralelo e compare os resultados.
- Investigue quaisquer falhas no Apidog que não apareçam no ReadyAPI.
- Adicione gradualmente novos casos de teste apenas no Apidog.
Assim que tiver confiança de que o Apidog detecta as mesmas falhas que o ReadyAPI, remova o ReadyAPI do pipeline de CI. Mantenha a instalação do ReadyAPI disponível por alguns meses como um fallback.
FAQ
Quanto tempo geralmente leva uma migração do ReadyAPI para o Apidog?Um projeto REST-only com scripting Groovy mínimo pode migrar em um a três dias. Um projeto grande com scripts Groovy extensos, casos de teste SOAP e estruturas de teste complexas pode levar de duas a seis semanas. A auditoria no Passo 1 fornece a estimativa mais clara antes de você se comprometer.
Meus arquivos de dados de teste do ReadyAPI funcionarão no Apidog?Arquivos de dados CSV funcionam com o recurso de teste orientado a dados do Apidog. O formato de importação é semelhante. Arquivos Excel exigem conversão para CSV primeiro. Arquivos de dados XML precisam ser reestruturados dependendo de como foram usados no ReadyAPI.
Posso executar o ReadyAPI e o Apidog no mesmo pipeline de CI durante a migração?Sim, e esta é a abordagem recomendada. Adicione a etapa do CLI do Apidog ao seu pipeline existente, junto com a etapa do testrunner do ReadyAPI. Compare os resultados execução por execução durante o período de transição.
Preciso recriar ambientes manualmente ou existe uma forma automatizada?A configuração do ambiente deve ser recriada manualmente no Apidog. Não há importação automatizada das configurações de ambiente do ReadyAPI. Mantenha seus ambientes ReadyAPI abertos em uma janela enquanto os recria no Apidog.
O que acontece com os testes do ReadyAPI que não possuem equivalente REST?Para casos de teste apenas SOAP sem alternativa REST, as opções práticas são manter o ReadyAPI (possivelmente com menos licenças) para esses testes específicos, migrar para o SoapUI Open Source, ou aceitar uma lacuna de teste se os serviços forem legados e de baixo risco.
O Apidog suporta os mesmos tipos de asserção que o ReadyAPI?O Apidog suporta asserções JavaScript que podem expressar as mesmas condições lógicas que os tipos de asserção embutidos do ReadyAPI. A sintaxe é diferente, mas as capacidades são comparáveis para testes REST. Alguns tipos de asserção específicos do ReadyAPI (SOAP Fault, WS-Security) não têm equivalente no Apidog.
A migração do ReadyAPI para o Apidog é um projeto significativo, não uma tarefa de uma tarde. Equipes que planejam cuidadosamente, começam com uma auditoria clara, migram os casos de teste REST primeiro e executam ambas as ferramentas em paralelo durante a transição, a completam sem lacunas de cobertura ou regressões de teste.