Cómo Migrar de ReadyAPI a Apidog

Resumen

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

Introducción

Migrar la infraestructura de pruebas de API es una de esas tareas que parece sencilla hasta que se empieza. Los proyectos de ReadyAPI pueden contener años de casos de prueba acumulados, scripts Groovy personalizados, archivos de datos, entornos y estructuras complejas de suites de prueba. Para trasladar todo eso a Apidog, es necesario comprender qué se transfiere automáticamente, qué necesita conversión manual y qué puede decidir dejar atrás.

Esta guía detalla el proceso de migración paso a paso. Cubre la exportación de su proyecto ReadyAPI, el análisis de lo que tiene, la importación a Apidog, la gestión de la conversión de Groovy a JavaScript, la configuración de CI/CD y la gestión del período de transición en el que ambas herramientas se ejecutan en paralelo.

Paso 1: Audite su proyecto ReadyAPI antes de empezar

Antes de exportar nada, dedique tiempo a comprender qué hay en su proyecto ReadyAPI actual. Esta auditoría determinará cuánto tiempo llevará la migración y dónde concentrará sus esfuerzos.

Abra su proyecto ReadyAPI y responda estas preguntas:

¿Cuántas suites de pruebas, casos de prueba y pasos de prueba tiene? Abra el panel del Navegador y cuente. Un proyecto con 50 casos de prueba migra en horas. Un proyecto con 500 toma días.

¿Qué porcentaje son casos de prueba REST vs SOAP? Los casos de prueba REST migran mucho más limpiamente. Los casos de prueba SOAP requieren más trabajo manual, especialmente si utilizan políticas de WS-Security o aserciones complejas.

¿Cuánto scripting Groovy hay en sus casos de prueba? Navegue por sus casos de prueba y busque los pasos de Script. Cuente cuántos casos de prueba tienen lógica Groovy personalizada. Cada script Groovy requiere una conversión manual a JavaScript.

¿Está utilizando pruebas basadas en datos con pasos de DataSource? Apidog admite pruebas basadas en datos con archivos CSV y JSON, pero la configuración es diferente del patrón DataSource/DataSink de ReadyAPI.

¿Utiliza mucho los pasos de Properties o Property Transfer? Estos patrones funcionan de manera diferente en Apidog. En su lugar, utilizará variables y variables de entorno.

¿Está ejecutando pruebas de carga a través de LoadUI Pro? La integración de LoadUI Pro no se traslada a Apidog. Tendrá que configurar k6 u otra herramienta de pruebas de carga por separado para esos escenarios.

Documente sus hallazgos. Una hoja de cálculo con el nombre del caso de prueba, el tipo (REST/SOAP), si tiene Groovy (sí/no) y la complejidad (simple/media/compleja) le dará una estimación de la migración antes de empezar.

Paso 2: Exporte su proyecto ReadyAPI

ReadyAPI almacena los proyectos como archivos XML. Para exportar un proyecto para su análisis:

1. Abra ReadyAPI y abra su proyecto.
2. Vaya a Archivo > Guardar como para guardar el proyecto como un archivo XML independiente.
3. Guarde cualquier archivo de datos externo (CSV, Excel, datos de prueba XML) a los que hagan referencia sus pruebas.
4. Anote cualquier configuración de entorno que haya configurado en la sección Entornos.

El XML del proyecto contiene todas las suites de prueba, casos de prueba, pasos de prueba, scripts y configuración. Es una representación completa de su proyecto de prueba.

Paso 3: Extraiga sus definiciones de API

La ruta de migración más limpia para las API REST pasa por una especificación OpenAPI, no directamente desde el XML del proyecto ReadyAPI.

Opción A: Exportar desde ReadyAPI. Si tiene un servicio REST en ReadyAPI, haga clic derecho sobre él en el Navegador y busque una opción para exportar o generar la definición de API. ReadyAPI puede exportar especificaciones Swagger/OpenAPI desde las definiciones de servicio.

Opción B: Utilice la especificación OpenAPI de su backend. Si su servicio backend ya expone una especificación OpenAPI (en /openapi.json o similar), descárguela directamente. Esto le dará la definición más precisa y actual.

Opción C: Extraer manualmente. Para API sin una especificación existente, use sus solicitudes REST de ReadyAPI como fuente. Anote los endpoints, cuerpos de solicitud, encabezados y estructuras de respuesta. Los recreará en Apidog.

Paso 4: Importar a Apidog

Con su especificación OpenAPI lista, impórtela a Apidog.

1. Abra Apidog y cree un nuevo proyecto.
2. Vaya a API > Importar y seleccione su formato (OpenAPI 3.0, Swagger 2.0, etc.).
3. Suba el archivo de especificación o pegue la URL.
4. Apidog analiza la especificación y crea definiciones de API para todos los endpoints.

Después de la importación, tendrá una definición de API estructurada con todos los endpoints, parámetros, cuerpos de solicitud y esquemas de respuesta rellenados. Esta es la base para sus casos de prueba.

Si tiene colecciones de Postman existentes (quizás migradas de una herramienta anterior), Apidog también las importa a través de Archivo > Importar > Postman.

Paso 5: Recrear casos de prueba para endpoints REST

Para los casos de prueba REST, el proceso de migración es:

1. Abra un caso de prueba REST de ReadyAPI.
2. Identifique las solicitudes, aserciones y cualquier fuente de datos que utilice.
3. Cree un caso de prueba correspondiente en Apidog seleccionando el endpoint de la API y añadiendo pasos de prueba.

Las aserciones se traducen de la siguiente manera:

• La aserción de "Contiene" (el cuerpo contiene una cadena) se convierte en una aserción JavaScript: pm.test('contains value', () => { pm.expect(pm.response.text()).to.include('expected string'); });
• Aserción de código de estado: pm.test('status 200', () => { pm.response.to.have.status(200); });
• Aserciones JSONPath: pm.test('field value', () => { pm.expect(pm.response.json().fieldName).to.equal('expected'); });

Para pruebas GET y POST directas sin Groovy, esta migración es rápida. Un caso de prueba simple con 5 a 10 aserciones puede recrearse en 15 a 30 minutos.

Paso 6: Convertir scripts Groovy a JavaScript

Esta es la parte más laboriosa de la migración para proyectos con un scripting personalizado significativo.

Patrones comunes de Groovy y sus equivalentes en JavaScript:

Lectura de un valor de respuesta:

// 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;

Establecer una variable:

// Groovy
testRunner.testCase.setPropertyValue('myVariable', someValue)

// JavaScript
pm.variables.set('myVariable', someValue);

Aserciones condicionales:

// 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');
  });
}

Manipulación de fechas:

// 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 complejos con importaciones de librerías Java o lógica intrincada, la conversión requiere un análisis cuidadoso. Lea cada script, comprenda lo que hace y escriba el JavaScript equivalente. No intente una traducción automática: la semántica es lo suficientemente parecida como para engañarle, pero lo suficientemente diferente como para causar errores silenciosos.

Paso 7: Gestionar casos de prueba SOAP

Los casos de prueba SOAP son la parte más desafiante de cualquier migración de ReadyAPI. Apidog no tiene herramientas dedicadas para SOAP, por lo que estos requieren un enfoque diferente.

Para los servicios SOAP que también exponen una interfaz REST (lo cual es cada vez más común), migre las pruebas para que utilicen los endpoints REST y elimine la capa SOAP.

Para los servicios SOAP sin alternativa REST, tiene dos opciones:

Mantener ReadyAPI solo para SOAP. Ejecute ReadyAPI en paralelo para los casos de prueba SOAP y use Apidog para REST. Este es un punto intermedio práctico que mantiene la cobertura de SOAP sin bloquear la migración REST.

Usar SoapUI Open Source. SoapUI Open Source es gratuito y maneja las pruebas SOAP. No puede reemplazar todas las características de ReadyAPI, pero cubre las pruebas funcionales SOAP básicas sin costo de licencia.

No se apresure con la migración SOAP. Los casos de prueba de WS-Security, en particular, conllevan un riesgo significativo si sus aserciones no se reproducen cuidadosamente.

Paso 8: Configurar entornos y variables

La función de entorno de ReadyAPI se asigna al sistema de entorno de Apidog. Para cada entorno de ReadyAPI que haya configurado:

1. Cree un entorno coincidente en Apidog (Configuración > Entornos).
2. Añada las mismas variables: URLs base, tokens de autenticación, encabezados compartidos, etc.
3. Verifique que los casos de prueba hagan referencia a las variables con la sintaxis correcta de Apidog: {{variableName}} en campos de URL y cuerpos de solicitud.

Paso 9: Configurar CI/CD

La configuración de CI de ReadyAPI típicamente implica el comando testrunner en los agentes de compilación. Apidog utiliza un enfoque diferente.

Instale la CLI de Apidog en su agente de CI:

npm install -g apidog-cli

Ejecute una colección de pruebas:

apidog run "path/to/collection.json" -e "environment-id"

Para GitHub Actions, un paso del flujo de trabajo podría verse así:

- name: Run API tests
  run: apidog run collection.json --environment staging

Para Jenkins, añada un paso de shell a su pipeline que llame a la CLI de Apidog. No se requiere instalación de ReadyAPI en el agente de compilación.

Actualice sus archivos de configuración de CI para usar el nuevo comando. Elimine las referencias de ReadyAPI testrunner una vez que las ejecuciones de Apidog se validen correctamente.

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

No cambie de ReadyAPI a Apidog en un solo día. Ejecute ambas herramientas en paralelo durante al menos un ciclo de lanzamiento.

Durante el período paralelo:

• Ejecute las pruebas de ReadyAPI en CI como la puerta de prueba autoritativa.
• Ejecute las pruebas de Apidog en paralelo y compare los resultados.
• Investigue cualquier fallo en Apidog que no aparezca en ReadyAPI.
• Añada gradualmente nuevos casos de prueba solo en Apidog.

Una vez que tenga la confianza de que Apidog detecta los mismos fallos que ReadyAPI, elimine ReadyAPI del pipeline de CI. Mantenga la instalación de ReadyAPI disponible durante unos meses como respaldo.

Preguntas Frecuentes

¿Cuánto tiempo suele durar una migración de ReadyAPI a Apidog?Un proyecto solo REST con un scripting Groovy mínimo puede migrar en uno a tres días. Un proyecto grande con scripts Groovy extensos, casos de prueba SOAP y estructuras de prueba complejas puede llevar de dos a seis semanas. La auditoría en el Paso 1 le da la estimación más clara antes de comprometerse.

¿Funcionarán mis archivos de datos de prueba de ReadyAPI en Apidog?Los archivos de datos CSV funcionan con la función de pruebas basadas en datos de Apidog. El formato de importación es similar. Los archivos de Excel requieren una conversión a CSV primero. Los archivos de datos XML deben reestructurarse dependiendo de cómo se usaron en ReadyAPI.

¿Puedo ejecutar ReadyAPI y Apidog en el mismo pipeline de CI durante la migración?Sí, y este es el enfoque recomendado. Añada el paso de la CLI de Apidog a su pipeline existente junto con el paso de testrunner de ReadyAPI. Compare los resultados ejecución por ejecución durante el período de transición.

¿Necesito recrear los entornos manualmente o hay una forma automatizada?La configuración del entorno debe recrearse manualmente en Apidog. No hay importación automatizada de la configuración de entornos de ReadyAPI. Mantenga sus entornos de ReadyAPI abiertos en una ventana mientras los recrea en Apidog.

¿Qué sucede con las pruebas de ReadyAPI que no tienen un equivalente REST?Para los casos de prueba solo SOAP sin alternativa REST, las opciones prácticas son mantener ReadyAPI (posiblemente con menos licencias) para esas pruebas específicas, migrar a SoapUI Open Source, o aceptar una brecha de pruebas si los servicios son heredados y de bajo riesgo.

¿Apidog soporta los mismos tipos de aserciones que ReadyAPI?Apidog soporta aserciones JavaScript que pueden expresar las mismas condiciones lógicas que los tipos de aserciones incorporados de ReadyAPI. La sintaxis es diferente, pero las capacidades son comparables para las pruebas REST. Algunos tipos de aserciones específicos de ReadyAPI (SOAP Fault, WS-Security) no tienen equivalente en Apidog.

La migración de ReadyAPI a Apidog es un proyecto significativo, no una tarea de una tarde. Los equipos que la planifican cuidadosamente, comienzan con una auditoría clara, migran primero los casos de prueba REST y ejecutan ambas herramientas en paralelo durante la transición, la completan sin lagunas en la cobertura o regresiones en las pruebas.