DEV Community

Cover image for Cómo Migrar de ReadyAPI a Apidog
Roobia
Roobia

Posted on • Originally published at apidog.com

Cómo Migrar de ReadyAPI a Apidog

Resumen

La migración de ReadyAPI a Apidog es directa para suites de pruebas principalmente REST. Exporte su proyecto ReadyAPI, convierta lo que pueda mediante importación de OpenAPI y transcriba los scripts Groovy manualmente a JavaScript. Los casos de prueba SOAP requieren más trabajo manual. Planifique una migración por fases para mantener la cobertura de pruebas continua.

Prueba Apidog hoy

💡 Apidog es una plataforma gratuita de desarrollo de API todo en uno que importa especificaciones OpenAPI y colecciones de Postman, y ejecuta pipelines de prueba con scripts JavaScript. Pruebe Apidog gratis, no se requiere tarjeta de crédito.

Introducción

Migrar la infraestructura de pruebas de API puede ser un reto si su proyecto ReadyAPI acumula años de casos de prueba, scripts Groovy, archivos de datos y entornos personalizados. Para llevar todo a Apidog, debe identificar qué se migra automáticamente, qué requiere conversión manual, y qué puede prescindir.

Esta guía muestra paso a paso cómo exportar su proyecto ReadyAPI, analizar su contenido, importarlo en Apidog, convertir scripts Groovy a JavaScript, configurar CI/CD y gestionar la transición manteniendo ambas herramientas en paralelo.

Paso 1: Audite su proyecto ReadyAPI antes de empezar

Antes de exportar, entienda el alcance de su proyecto ReadyAPI. Este análisis determinará el esfuerzo de migración y dónde enfocarse.

Revise en ReadyAPI:

  • Cantidad de suites, casos y pasos de prueba: Cuente en el panel Navegador. Menos de 50 casos migran en horas; más de 500, en días.
  • Porcentaje de casos REST vs SOAP: REST migra fácilmente. SOAP requiere trabajo manual, sobre todo si usa WS-Security o aserciones avanzadas.
  • Uso de scripting Groovy: Localice pasos de Script. Cada uno requerirá reescritura en JavaScript.
  • Pruebas basadas en datos (DataSource): Apidog admite data-driven testing con CSV/JSON, pero la configuración difiere del patrón DataSource/DataSink de ReadyAPI.
  • Uso de Properties o Property Transfer: En Apidog usará variables y variables de entorno.
  • Pruebas de carga (LoadUI Pro): Deberá configurar k6 u otra herramienta aparte; no se migra a Apidog.

Documente estos puntos en una hoja de cálculo: nombre del caso, tipo (REST/SOAP), uso de Groovy, complejidad. Así estimará el tiempo de migración.

Paso 2: Exporte su proyecto ReadyAPI

ReadyAPI almacena proyectos en XML. Para exportar:

  1. Abra ReadyAPI y su proyecto.
  2. Vaya a Archivo > Guardar como y seleccione formato XML.
  3. Guarde archivos de datos externos (CSV, Excel, XML) referenciados en las pruebas.
  4. Anote la configuración de entornos desde la sección Entornos.

El archivo XML contendrá todas las definiciones relevantes para análisis y migración.

Paso 3: Extraiga sus definiciones de API

La migración más limpia para API REST es a través de una especificación OpenAPI.

  • Opción A: Desde ReadyAPI, haga clic derecho sobre el servicio REST y busque la opción de exportar/generar definición de API. Exporta Swagger/OpenAPI.
  • Opción B: Si su backend ya expone /openapi.json, descárguelo directamente.
  • Opción C: Si no hay especificación, revise las solicitudes REST en ReadyAPI y anote manualmente endpoints, cuerpos, headers y respuestas para recrearlos en Apidog.

Paso 4: Importe a Apidog

Con la especificación OpenAPI lista:

  1. Abra Apidog y cree un nuevo proyecto.
  2. Vaya a API > Importar y seleccione el formato (OpenAPI 3.0, Swagger 2.0, etc).
  3. Suba el archivo o pegue la URL.
  4. Apidog analizará la especificación y generará los endpoints.

Si tiene colecciones Postman, impórtelas en Archivo > Importar > Postman.

Al finalizar, tendrá la base estructurada de endpoints, parámetros y esquemas para construir los casos de prueba.

Paso 5: Recree casos de prueba para endpoints REST

Para cada caso REST:

  1. Abra el caso en ReadyAPI y revise solicitudes, aserciones y fuentes de datos.
  2. En Apidog, cree el caso de prueba seleccionando el endpoint y añada pasos de prueba.

Traducción de aserciones:

  • "Contiene": 
  pm.test('contains value', () => { pm.expect(pm.response.text()).to.include('expected string'); });
Enter fullscreen mode Exit fullscreen mode
  • Código de estado: 
  pm.test('status 200', () => { pm.response.to.have.status(200); });
Enter fullscreen mode Exit fullscreen mode
  • JSONPath: 
  pm.test('field value', () => { pm.expect(pm.response.json().fieldName).to.equal('expected'); });
Enter fullscreen mode Exit fullscreen mode

Casos simples (GET/POST sin Groovy) pueden migrarse en 15-30 minutos cada uno.

Paso 6: Convierta scripts Groovy a JavaScript

Para scripting personalizado:

Patrones comunes:

  • Leer valor de respuesta: 
  // Groovy (ReadyAPI)
  def response = context.expand('${TestStep#Response}')
  def json = new groovy.json.JsonSlurper().parseText(response)
  def value = json.fieldName
Enter fullscreen mode Exit fullscreen mode 
  // JavaScript (Apidog)
  const response = pm.response.json();
  const value = response.fieldName;
Enter fullscreen mode Exit fullscreen mode
  • Establecer variable: 
  testRunner.testCase.setPropertyValue('myVariable', someValue)
Enter fullscreen mode Exit fullscreen mode 
  pm.variables.set('myVariable', someValue);
Enter fullscreen mode Exit fullscreen mode
  • Aserciones condicionales: 
  if (statusCode == 200) {
    assert responseBody.contains("success")
  }
Enter fullscreen mode Exit fullscreen mode 
  if (pm.response.code === 200) {
    pm.test('response contains success', () => {
      pm.expect(pm.response.text()).to.include('success');
    });
  }
Enter fullscreen mode Exit fullscreen mode
  • Manipulación de fechas: 
  def now = new Date()
  def formatted = now.format('yyyy-MM-dd')
Enter fullscreen mode Exit fullscreen mode 
  const now = new Date();
  const formatted = now.toISOString().split('T')[0];
Enter fullscreen mode Exit fullscreen mode

Para scripts complejos, analícelos cuidadosamente y escriba el equivalente en JavaScript. No confíe en traducciones automáticas.

Paso 7: Gestione casos de prueba SOAP

Migrar pruebas SOAP es lo más laborioso:

  • Si el servicio SOAP ofrece interfaz REST, migre los tests hacia REST y elimine SOAP.
  • Si no hay REST:
    • Opción 1: Mantenga ReadyAPI solo para SOAP y use Apidog para REST.
    • Opción 2: Use SoapUI Open Source para pruebas SOAP funcionales básicas.

No migre SOAP apresuradamente, especialmente si usa WS-Security.

Paso 8: Configure entornos y variables

Para cada entorno de ReadyAPI:

  1. Cree el entorno correspondiente en Apidog (Configuración > Entornos).
  2. Añada las mismas variables: URLs, tokens, headers, etc.
  3. Asegúrese de referenciar variables en Apidog con {{variableName}} en URL y cuerpos.

Paso 9: Configure CI/CD

En ReadyAPI, se usaba testrunner. Apidog usa su propia CLI.

Ejemplo de instalación y ejecución:

npm install -g apidog-cli
apidog run "path/to/collection.json" -e "environment-id"
Enter fullscreen mode Exit fullscreen mode

GitHub Actions:

- name: Run API tests
  run: apidog run collection.json --environment staging
Enter fullscreen mode Exit fullscreen mode

Jenkins: Añada un paso shell llamando a la CLI de Apidog.

Actualice sus pipelines CI y elimine referencias a testrunner cuando valide la ejecución con Apidog.

Paso 10: Ejecute ambas herramientas en paralelo durante la transición

No cambie de ReadyAPI a Apidog de golpe. Ejecute ambas en paralelo por al menos un ciclo de release.

Durante este periodo:

  • ReadyAPI sigue como fuente de verdad en CI.
  • Apidog se ejecuta en paralelo; compare resultados.
  • Investigue discrepancias en fallos.
  • Añada nuevos casos solo en Apidog.

Cuando confíe en Apidog, elimine ReadyAPI del pipeline, pero mantenga disponible como respaldo temporal.

Preguntas Frecuentes

¿Cuánto tiempo lleva migrar ReadyAPI a Apidog?

Proyectos REST pequeños y sin mucho Groovy migran en 1-3 días. Proyectos grandes con Groovy, SOAP y estructuras complejas pueden llevar 2-6 semanas. Use la auditoría inicial para estimar.

¿Funcionan mis archivos de datos de ReadyAPI en Apidog?

Archivos CSV funcionan. Excel debe convertirse a CSV. XML depende de su uso; puede requerir reestructuración.

¿Se pueden ejecutar ReadyAPI y Apidog en el mismo pipeline CI?

Sí, y es lo recomendable. Añada el paso de Apidog CLI junto al de ReadyAPI y compare resultados durante la transición.

¿La configuración de entornos se importa?

Debe recrearse manualmente en Apidog. Mantenga la configuración de ReadyAPI abierta mientras lo hace.

¿Qué pasa con pruebas de ReadyAPI sin equivalente REST?

Para SOAP sin REST, puede mantener ReadyAPI (menos licencias), migrar a SoapUI Open Source, o aceptar dejar de testear servicios heredados y de bajo riesgo.

¿Apidog soporta los mismos tipos de aserciones?

Apidog soporta aserciones JavaScript que cubren lo esencial de REST. Las aserciones específicas de ReadyAPI (SOAP Fault, WS-Security) no tienen equivalente directo.

Migrar de ReadyAPI a Apidog requiere planificación: audite su proyecto, migre REST primero, convierta scripts con cuidado, y ejecute ambas plataformas en paralelo. Así evitará brechas de cobertura y regresiones en sus pruebas.

Top comments (0)