DEV Community

Cover image for Migrer de ReadyAPI à Apidog
Antoine Laurent
Antoine Laurent

Posted on • Originally published at apidog.com

Migrer de ReadyAPI à Apidog

En bref

La migration de ReadyAPI vers Apidog est directe pour les suites de tests REST. Exportez votre projet ReadyAPI, importez les API via une spécification OpenAPI, puis recréez les scripts Groovy en JavaScript. Les cas de test SOAP demandent plus de travail manuel. Privilégiez une migration progressive pour garantir la continuité des tests.

Essayez Apidog dès aujourd'hui

💡 Apidog est une plateforme de développement API tout-en-un gratuite qui importe les spécifications OpenAPI et les collections Postman, et exécute des pipelines de test avec des scripts JavaScript. Essayez Apidog gratuitement, aucune carte de crédit requise.

Introduction

Migrer une infrastructure de test API n’est jamais trivial. Les projets ReadyAPI accumulent souvent des années de cas de test, scripts Groovy personnalisés, fichiers de données et structures complexes. Pour une migration efficace vers Apidog, il est essentiel de distinguer ce qui peut être importé automatiquement, ce qui doit être migré manuellement, et ce qui peut être laissé de côté.

Ce guide détaille chaque étape de la migration : export du projet ReadyAPI, analyse de son contenu, import dans Apidog, conversion Groovy → JavaScript, configuration CI/CD, gestion de la période de transition avec exécution parallèle des deux outils.

Étape 1 : Auditez votre projet ReadyAPI

Commencez par inventorier votre projet ReadyAPI. Cet audit oriente la charge de migration.

Questions à traiter :

  • Nombre de suites, cas de test et étapes de test ? Utilisez le panneau Navigateur pour compter.
  • Répartition REST vs SOAP ? Les tests REST migrent facilement, les SOAP nécessitent plus de travaux manuels, surtout avec WS-Security.
  • Quantité de scripts Groovy ? Parcourez tous les cas de test, notez ceux qui incluent des scripts personnalisés.
  • Tests basés sur des données (DataSource) ? Apidog gère CSV/JSON, mais la configuration diffère du modèle ReadyAPI.
  • Usage des étapes Propriétés/Transfert de Propriétés ? Prévoyez de les convertir en variables/environnements Apidog.
  • Tests de charge via LoadUI Pro ? Cette intégration n’est pas transférable ; prévoyez k6 ou un autre outil pour la charge.

Consignez vos résultats dans un tableau (nom, type, présence de Groovy, complexité). Cela fournit une estimation et facilite la planification.

Étape 2 : Exportez votre projet ReadyAPI

Pour un export complet :

  1. Ouvrez ReadyAPI et votre projet.
  2. Fichier > Enregistrer sous → exportez le projet sous forme de fichier XML.
  3. Sauvegardez tous les fichiers de données externes (CSV, Excel, XML).
  4. Notez vos environnements dans la section dédiée.

Le XML exporté regroupe toutes les suites de tests, étapes, scripts et configurations.

Étape 3 : Extrayez vos définitions d’API

Pour les API REST, privilégiez l’import via OpenAPI :

  • Option A : Export ReadyAPI Clic droit sur le service REST > Exporter la spécification (Swagger/OpenAPI).
  • Option B : Utilisez la spec backend Téléchargez directement /openapi.json si disponible.
  • Option C : Extraction manuelle Listez les endpoints, corps de requête, en-têtes et réponses à partir des requêtes REST existantes. Vous les recréerez manuellement dans Apidog.

Étape 4 : Importez dans Apidog

Une fois la spec OpenAPI prête :

  1. Créez un projet dans Apidog.
  2. Allez dans API > Importer et sélectionnez le format (OpenAPI 3.0, Swagger 2.0…).
  3. Uploadez le fichier ou collez l’URL.
  4. Apidog génère automatiquement la structure des endpoints, paramètres, schémas de requête/réponse.

Astuce : Apidog permet aussi d’importer des collections Postman (Fichier > Importer > Postman).

Étape 5 : Recréez les cas de test REST

Pour chaque cas de test REST :

  1. Ouvrez le cas ReadyAPI, identifiez requêtes, assertions, sources de données.
  2. Dans Apidog, créez le test correspondant à partir du bon endpoint.
  3. Ajoutez les étapes de test, assertions et jeux de données.

Exemples d’assertions :

  • Assertion “contient” : 
  pm.test('contient la valeur', () => {
    pm.expect(pm.response.text()).to.include('chaîne attendue');
  });
Enter fullscreen mode Exit fullscreen mode
  • Assertion statut HTTP : 
  pm.test('statut 200', () => {
    pm.response.to.have.status(200);
  });
Enter fullscreen mode Exit fullscreen mode
  • Assertion JSONPath : 
  pm.test('valeur de champ', () => {
    pm.expect(pm.response.json().nomDeChamp).to.equal('attendu');
  });
Enter fullscreen mode Exit fullscreen mode

Les tests GET/POST sans Groovy se recréent rapidement. Un cas simple (5-10 assertions) se migre en 15-30 minutes.

Étape 6 : Convertissez les scripts Groovy en JavaScript

La migration des scripts personnalisés est la partie la plus technique.

Correspondances courantes :

  • Lecture d’une valeur de réponse : 
  // 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
  • Définir une variable : 
  testRunner.testCase.setPropertyValue('myVariable', someValue)
Enter fullscreen mode Exit fullscreen mode 
  pm.variables.set('myVariable', someValue);
Enter fullscreen mode Exit fullscreen mode
  • Assertion conditionnelle : 
  if (statusCode == 200) {
    assert responseBody.contains("success")
  }
Enter fullscreen mode Exit fullscreen mode 
  if (pm.response.code === 200) {
    pm.test('la réponse contient succès', () => {
      pm.expect(pm.response.text()).to.include('success');
    });
  }
Enter fullscreen mode Exit fullscreen mode
  • Manipulation de date : 
  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

Pour chaque script complexe, analysez la logique puis réécrivez-la soigneusement en JavaScript. Évitez la traduction automatique : la proximité syntaxique Groovy/JS peut masquer des différences subtiles et générer des bugs.

Étape 7 : Gérez les cas de test SOAP

Les tests SOAP demandent une approche spécifique :

  • Si une interface REST existe, privilégiez la migration vers REST.
  • Sinon, vous pouvez :
    • Garder ReadyAPI uniquement pour SOAP (exécution en parallèle pour SOAP, Apidog pour REST)
    • Utiliser SoapUI Open Source pour les tests fonctionnels SOAP basiques.

Les cas WS-Security sont à traiter avec précaution : analysez chaque assertion, migrez-les avec soin.

Étape 8 : Configurez les environnements et les variables

Pour chaque environnement ReadyAPI :

  1. Créez l’environnement équivalent dans Apidog (Paramètres > Environnements).
  2. Ajoutez les variables nécessaires (URL base, jetons, en-têtes…).
  3. Référencez-les dans vos tests via {{nomDeVariable}}.

Étape 9 : Configurez l’intégration continue/déploiement continu (CI/CD)

Contrairement à ReadyAPI (commande testrunner), Apidog propose une CLI nodejs.

Installation :

npm install -g apidog-cli
Enter fullscreen mode Exit fullscreen mode

Exécution d’une collection de tests :

apidog run "chemin/vers/collection.json" -e "id-environnement"
Enter fullscreen mode Exit fullscreen mode

Exemple GitHub Actions :

- name: Exécuter les tests API
  run: apidog run collection.json --environment staging
Enter fullscreen mode Exit fullscreen mode

Exemple Jenkins : ajoutez une étape shell qui lance la CLI Apidog.

Mettez à jour vos scripts CI pour remplacer les appels ReadyAPI par ceux d’Apidog une fois validés.

Étape 10 : Exécutez les deux outils en parallèle

Ne basculez pas tout en une journée. Pendant la transition :

  • Continuez à exécuter ReadyAPI comme référence dans la CI.
  • Exécutez les tests Apidog en parallèle, comparez les résultats.
  • Corrigez les écarts, migrez les nouveaux tests uniquement sur Apidog.
  • Lorsque les résultats sont cohérents, retirez ReadyAPI de la CI mais gardez-le accessible quelques mois si besoin.

FAQ

Combien de temps prend la migration ReadyAPI vers Apidog ?

Un projet REST sans script complexe migre en 1 à 3 jours. Un gros projet avec beaucoup de Groovy, des tests SOAP, etc. prend 2 à 6 semaines. L’audit initial est clé pour estimer.

Les fichiers de données ReadyAPI sont-ils compatibles ?

CSV : oui. Excel : convertir en CSV. XML : à adapter selon l’usage.

Puis-je exécuter ReadyAPI et Apidog dans le même pipeline CI ?

Oui, recommandé. Ajoutez l’étape Apidog CLI, comparez les résultats.

Faut-il recréer les environnements manuellement ?

Oui, il n’existe pas d’import automatique. Ouvrez les environnements ReadyAPI en parallèle pour la configuration.

Que faire des tests ReadyAPI sans équivalent REST ?

Maintenez ReadyAPI (avec moins de licences si possible), migrez sur SoapUI Open Source, ou acceptez une lacune si la couverture n’est plus critique.

Apidog couvre-t-il les mêmes assertions que ReadyAPI ?

Les assertions JavaScript couvrent l’essentiel des besoins REST. Les assertions spécifiques SOAP/WS-Security n’ont pas d’équivalent direct.

La migration ReadyAPI vers Apidog est un projet structurant. En auditant d’abord, migrant les REST en priorité et en exécutant les deux outils en parallèle, vous évitez toute perte de couverture ou régression.

Top comments (0)