OpenAPI2SoapUI: de horas de click a segundos de automatización
Cualquiera que haya trabajado con SoapUI conoce la parte tediosa del proceso: antes de escribir una sola aserción hay que reconstruir a mano toda la API dentro de la herramienta. Crear el servicio REST, definir los endpoints, dar de alta cada recurso y cada método, escribir las requests con sus cabeceras, sus parámetros y sus cuerpos de ejemplo, y solo entonces empezar a montar los test cases. Cuando la especificación tiene decenas de operaciones, esa preparación se convierte en horas de trabajo repetitivo y propenso a errores.
OpenAPI2SoapUI, la herramienta open source de la comunidad APIAddicts, elimina ese trabajo manual. A partir de tu especificación OpenAPI —tanto v2 (la antigua Swagger) como v3— genera automáticamente un proyecto de SoapUI completo, con las requests de cada operación y una test suite lista para importar. Lo que antes eran horas de clic-a-clic pasa a resolverse en una única llamada a la API.
Qué es OpenAPI2SoapUI
OpenAPI2SoapUI es una API construida sobre Spring Boot que recibe una especificación OpenAPI y devuelve el contenido de un proyecto de SoapUI en formato XML. Ese XML se guarda como archivo y se importa directamente en la aplicación SoapUI, quedando listo para ejecutar pruebas funcionales sin ningún montaje previo.
La idea de fondo es sencilla y potente:
Tu contrato de API ya contiene toda la información necesaria para probar la API.
Rutas, verbos, parámetros, cuerpos de petición, ejemplos, esquemas de seguridad… todo está en el documento OpenAPI. En lugar de traducir manualmente ese contrato a un proyecto de pruebas, OpenAPI2SoapUI hace la traducción por ti, de forma sistemática y reproducible.
Por qué importa: del contrato a las pruebas sin fricción
Adoptar un enfoque API-first significa que la especificación OpenAPI es la fuente de verdad del proyecto. Sin embargo, esa fuente de verdad a menudo se queda en documentación: describe la API, pero no se aprovecha para acelerar el resto del ciclo de vida. OpenAPI2SoapUI cierra precisamente ese hueco entre el diseño y la validación.
- Ahorro de tiempo drástico. La preparación de un proyecto SoapUI deja de medirse en horas para medirse en segundos.
- Consistencia total. Todos los proyectos se generan con la misma nomenclatura y estructura, lo que facilita el mantenimiento y la colaboración entre equipos.
- Menos errores humanos. Al eliminar la transcripción manual de rutas, parámetros y cuerpos, desaparecen los típicos fallos de copiar y pegar.
- Sincronización con el contrato. Cuando la API evoluciona, basta con regenerar el proyecto a partir de la nueva especificación para tener las pruebas alineadas.
- Cobertura desde el primer minuto. Cada operación llega con su test suite asociada, de modo que el equipo de QA parte de una base sólida en lugar de una hoja en blanco.
Qué genera exactamente
OpenAPI2SoapUI no se limita a crear peticiones sueltas: reconstruye la API dentro de SoapUI con un nivel de detalle notable. Entre sus funcionalidades destacan:
- Decodificación en Base64 del contenido de la especificación OpenAPI y su análisis (parsing) a la representación de swagger-core como POJO de Java.
- Creación del proyecto de SoapUI y alta del servicio REST con sus endpoints y su
basePath. - Incorporación de los recursos (rutas) y de los métodos (verbos y operaciones) de cada recurso.
- Configuración de la request REST de cada método, con sus ejemplos de parámetros, su cuerpo de petición de ejemplo y sus cabeceras personalizadas.
- Añadido de perfiles OAuth 2.0 al proyecto y asignación de credenciales a cada petición.
- Generación de TestSuites por cada método, con sus TestCases y un Test Step de ejecución (la petición REST) en cada uno.
Una nomenclatura predecible
Uno de los grandes aciertos de la herramienta es que aplica una convención de nombres coherente y predecible a todo lo que crea, de modo que cualquier persona del equipo pueda orientarse en el proyecto generado: el proyecto se nombra como {apiName}_{apiVersion}, el servicio REST como {apiName}, cada recurso según su {path}, los métodos con el verbo HTTP en mayúsculas, y las test suites siguiendo el patrón {path}_{httpMethod}_TestSuite. Los valores se toman directamente del contrato: el nombre y la versión de la sección info, y las rutas y métodos de las paths definidas en el documento OpenAPI.
El stack tecnológico
OpenAPI2SoapUI está construido con un stack Java empresarial, sólido y ampliamente conocido: su núcleo es Spring Boot 2 sobre JDK 11, con Maven 3 para la gestión de dependencias y despliegue como WAR en Tomcat 9. Se apoya en Lombok para reducir el código repetitivo, Hibernate Validator para las validaciones y Springdoc OpenAPI UI para exponer su propia documentación. El motor de conversión combina el módulo core de SoapUI —la herramienta líder para pruebas funcionales de SOAP y REST— con Swagger Parser, que analiza definiciones OpenAPI en JSON o YAML.
Cómo empezar
Poner en marcha OpenAPI2SoapUI en local es directo. Los requisitos previos son una instalación de JDK, de Apache Maven y la configuración de Lombok en tu IDE (compatible con Eclipse, IntelliJ IDEA, NetBeans y Visual Studio Code). Conviene tener en cuenta una particularidad: el proyecto utiliza el módulo SoapUI Core, que no es una dependencia estándar de Maven, por lo que necesitarás acceso a internet para descargarla desde el repositorio externo de SmartBear declarado en el pom.xml.
A partir de ahí, tienes varias formas de arrancar la aplicación: ejecutando la clase principal desde el IDE, con Maven mediante mvn spring-boot:run, con Docker (mvn clean package -Pjar y docker-compose up -d) o desplegando el WAR generado con mvn clean package en un Tomcat. Una vez levantado el servicio, el endpoint para generar proyectos queda disponible en una ruta del tipo /api-openapi-to-soapui/v1/soap-ui-projects: envías tu especificación OpenAPI en el cuerpo de la petición y recibes de vuelta el XML del proyecto de SoapUI, listo para importar. El repositorio incluye además un ejemplo con cURL y una interfaz Swagger UI para explorar la API de forma interactiva.
Casos de uso reales
OpenAPI2SoapUI encaja de forma natural en varios escenarios habituales del ciclo de vida de las APIs. En equipos de QA, permite arrancar la batería de pruebas funcionales en cuanto el contrato está definido, sin esperar a que la implementación esté completa. En procesos de modernización y apificación —de hecho, así lo utilizan organizaciones como CloudAppi o RSI, presentes en la lista de adopters del proyecto— acelera la validación de los microservicios generados. Y en flujos de integración continua, ofrece una vía para mantener los proyectos de pruebas siempre sincronizados con la última versión de la especificación.
Open source y comunidad
OpenAPI2SoapUI es un proyecto de la comunidad APIAddicts, pensado para uso comunitario: se puede modificar y adaptar libremente sin uso comercial. Si tu organización necesita una versión concreta, soporte o ayuda para un proyecto empresarial, el equipo está disponible en [email protected]. Como todo proyecto abierto, crece con la participación de quienes lo usan: puedes contribuir a través del issue tracker de GitHub, sumarte a las discusiones de la comunidad y apoyar el proyecto con una estrella en el repositorio.
Conclusión
La filosofía API-first promete que el contrato sea el motor de todo el ciclo de vida de la API. OpenAPI2SoapUI hace tangible esa promesa en el terreno de las pruebas: convierte un documento OpenAPI en un proyecto de SoapUI funcional y estructurado, en cuestión de segundos y sin trabajo manual. Menos tiempo de preparación, más consistencia y menos errores, para que tu equipo pueda centrarse en lo que de verdad aporta valor: diseñar buenas pruebas y garantizar la calidad de la API.
Explora el proyecto en github.com/apiaddicts/openapi2soapui, pruébalo con tu propia especificación y cuéntanos qué te parece. En APIAddicts construimos herramientas abiertas para la comunidad de APIs.
