Migrer de ReadyAPI à Apidog

En bref

La migration de ReadyAPI vers Apidog est simple pour les suites de tests axées sur les API REST. Exportez votre projet ReadyAPI, convertissez ce que vous pouvez via l'importation OpenAPI, et recréez manuellement les scripts Groovy en JavaScript. Les cas de test SOAP nécessitent le plus de travail manuel. Prévoyez une migration par phases pour maintenir une couverture de test continue.

💡

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.

bouton

Introduction

La migration d'une infrastructure de test API est l'une de ces tâches qui semblent simples jusqu'à ce que l'on commence. Les projets ReadyAPI peuvent contenir des années de cas de test accumulés, de scripts Groovy personnalisés, de fichiers de données, d'environnements et de structures de suites de tests complexes. Transférer tout cela vers Apidog nécessite de comprendre ce qui se transfère automatiquement, ce qui nécessite une conversion manuelle, et ce que vous pourriez décider de laisser de côté.

Ce guide vous accompagne pas à pas dans le processus de migration. Il couvre l'exportation de votre projet ReadyAPI, l'analyse de son contenu, l'importation dans Apidog, la gestion de la conversion Groovy-vers-JavaScript, la configuration de l'intégration continue/déploiement continu (CI/CD) et la gestion de la période de transition lorsque les deux outils fonctionnent en parallèle.

Étape 1 : Auditez votre projet ReadyAPI avant de commencer

Avant d'exporter quoi que ce soit, prenez le temps de comprendre le contenu de votre projet ReadyAPI actuel. Cet audit déterminera la durée de la migration et l'endroit où vous concentrerez vos efforts.

Ouvrez votre projet ReadyAPI et répondez à ces questions :

Combien de suites de tests, de cas de test et d'étapes de test avez-vous ? Ouvrez le panneau Navigateur et comptez. Un projet avec 50 cas de test migre en quelques heures. Un projet avec 500 prend plusieurs jours.

Quel pourcentage sont des cas de test REST par rapport aux cas de test SOAP ? Les cas de test REST migrent beaucoup plus proprement. Les cas de test SOAP nécessitent plus de travail manuel, surtout s'ils utilisent des politiques WS-Security ou des assertions complexes.

Quelle est la quantité de scripts Groovy dans vos cas de test ? Parcourez vos cas de test et recherchez les étapes de script. Comptez le nombre de cas de test qui contiennent une logique Groovy personnalisée. Chaque script Groovy nécessite une conversion manuelle en JavaScript.

Utilisez-vous des tests basés sur les données avec des étapes DataSource ? Apidog prend en charge les tests basés sur les données avec des fichiers CSV et JSON, mais la configuration est différente de celle du modèle DataSource/DataSink de ReadyAPI.

Utilisez-vous beaucoup les étapes Propriétés ou Transfert de Propriétés ? Ces modèles fonctionnent différemment dans Apidog. Vous utiliserez plutôt des variables et des variables d'environnement.

Effectuez-vous des tests de charge via LoadUI Pro ? L'intégration de LoadUI Pro ne se reporte pas sur Apidog. Vous devrez configurer k6 ou un autre outil de test de charge séparément pour ces scénarios.

Documentez vos découvertes. Une feuille de calcul avec le nom du cas de test, le type (REST/SOAP), l'existence de Groovy (oui/non) et la complexité (simple/moyenne/complexe) vous donnera une estimation de la migration avant de commencer.

Étape 2 : Exportez votre projet ReadyAPI

ReadyAPI stocke les projets sous forme de fichiers XML. Pour exporter un projet à des fins d'analyse :

Ouvrez ReadyAPI et ouvrez votre projet.
Allez dans Fichier > Enregistrer sous pour enregistrer le projet en tant que fichier XML autonome.
Enregistrez tous les fichiers de données externes (CSV, Excel, données de test XML) auxquels vos tests font référence.
Notez toutes les configurations d'environnement que vous avez définies dans la section Environnements.

Le fichier XML du projet contient toutes les suites de tests, les cas de test, les étapes de test, les scripts et la configuration. Il s'agit d'une représentation complète de votre projet de test.

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

Le chemin de migration le plus propre pour les API REST passe par une spécification OpenAPI, et non directement par le fichier XML du projet ReadyAPI.

Option A : Exportation depuis ReadyAPI. Si vous avez un service REST dans ReadyAPI, cliquez dessus avec le bouton droit de la souris dans le Navigateur et recherchez une option d'exportation ou de génération de définition d'API. ReadyAPI peut exporter des spécifications Swagger/OpenAPI à partir de définitions de service.

Option B : Utilisez la spécification OpenAPI de votre backend. Si votre service backend expose déjà une spécification OpenAPI (à l'adresse /openapi.json ou similaire), téléchargez-la directement. Cela vous donne la définition la plus précise et la plus actuelle.

Option C : Extraction manuelle. Pour les API sans spécification existante, utilisez vos requêtes REST ReadyAPI comme source. Notez les points d'accès, les corps de requête, les en-têtes et les structures de réponse. Vous les recréerez dans Apidog.

Étape 4 : Importez dans Apidog

Une fois votre spécification OpenAPI prête, importez-la dans Apidog.

Ouvrez Apidog et créez un nouveau projet.
Allez dans API > Importer et sélectionnez votre format (OpenAPI 3.0, Swagger 2.0, etc.).
Téléchargez le fichier de spécification ou collez l'URL.
Apidog analyse la spécification et crée des définitions d'API pour tous les points d'accès.

Après l'importation, vous disposez d'une définition d'API structurée avec tous les points d'accès, les paramètres, les corps de requête et les schémas de réponse renseignés. C'est la base de vos cas de test.

Si vous avez des collections Postman existantes (peut-être migrées d'un outil précédent), Apidog les importe également via Fichier > Importer > Postman.

Étape 5 : Recréez les cas de test pour les points d'accès REST

Pour les cas de test REST, le processus de migration est le suivant :

Ouvrez un cas de test REST ReadyAPI.
Identifiez les requêtes, les assertions et toutes les sources de données qu'il utilise.
Créez un cas de test correspondant dans Apidog en sélectionnant le point d'accès API et en ajoutant des étapes de test.

Les assertions se traduisent comme suit :

Une assertion "contient" (le corps contient la chaîne) devient une assertion JavaScript : pm.test('contient la valeur', () => { pm.expect(pm.response.text()).to.include('chaîne attendue'); });
Assertion de code de statut : pm.test('statut 200', () => { pm.response.to.have.status(200); });
Assertions JSONPath : pm.test('valeur de champ', () => { pm.expect(pm.response.json().nomDeChamp).to.equal('attendu'); });

Pour les tests GET et POST simples sans Groovy, cette migration est rapide. Un cas de test simple avec 5 à 10 assertions peut être recréé en 15 à 30 minutes.

Étape 6 : Convertissez les scripts Groovy en JavaScript

C'est la partie la plus laborieuse de la migration pour les projets avec des scripts personnalisés importants.

Motifs Groovy courants et leurs équivalents JavaScript :

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

// JavaScript (Apidog)
const response = pm.response.json();
const value = response.fieldName;

Définition d'une variable :

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

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

Assertions conditionnelles :

// Groovy
if (statusCode == 200) {
  assert responseBody.contains("success")
}

// JavaScript
if (pm.response.code === 200) {
  pm.test('la réponse contient succès', () => {
    pm.expect(pm.response.text()).to.include('success');
  });
}

Manipulation de dates :

// Groovy
def now = new Date()
def formatted = now.format('yyyy-MM-dd')

// JavaScript
const now = new Date();
const formatted = now.toISOString().split('T')[0];

Pour les scripts Groovy complexes avec des importations de bibliothèques Java ou une logique complexe, la conversion nécessite une analyse minutieuse. Lisez chaque script, comprenez ce qu'il fait et écrivez l'équivalent en JavaScript. N'essayez pas de traduction automatisée – les sémantiques sont suffisamment proches pour vous tromper, mais suffisamment différentes pour provoquer des bugs silencieux.

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

Les cas de test SOAP sont la partie la plus difficile de toute migration ReadyAPI. Apidog ne dispose pas d'outils SOAP dédiés, ils nécessitent donc une approche différente.

Pour les services SOAP qui exposent également une interface REST (ce qui est de plus en plus courant), migrez les tests pour utiliser les points d'accès REST et supprimez la couche SOAP.

Pour les services SOAP sans alternative REST, vous avez deux options :

Conserver ReadyAPI uniquement pour le SOAP. Exécutez ReadyAPI en parallèle pour les cas de test SOAP et utilisez Apidog pour REST. C'est un compromis pratique qui maintient la couverture SOAP sans bloquer la migration REST.

Utiliser SoapUI Open Source. SoapUI Open Source est gratuit et gère les tests SOAP. Il ne peut pas remplacer toutes les fonctionnalités de ReadyAPI, mais il couvre les tests fonctionnels SOAP de base sans coût de licence.

Ne précipitez pas la migration SOAP. Les cas de test WS-Security, en particulier, comportent un risque important si leurs assertions ne sont pas reproduites avec soin.

Étape 8 : Configurez les environnements et les variables

La fonctionnalité d'environnement de ReadyAPI correspond au système d'environnement d'Apidog. Pour chaque environnement ReadyAPI que vous avez configuré :

Créez un environnement correspondant dans Apidog (Paramètres > Environnements).
Ajoutez les mêmes variables : URL de base, jetons d'authentification, en-têtes partagés, etc.
Vérifiez que les cas de test référencent les variables avec la syntaxe Apidog correcte : {{nomDeVariable}} dans les champs d'URL et les corps de requête.

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

La configuration de l'intégration continue de ReadyAPI implique généralement la commande testrunner sur les agents de build. Apidog utilise une approche différente.

Installez l'interface de ligne de commande (CLI) Apidog sur votre agent CI :

npm install -g apidog-cli

Exécutez une collection de tests :

apidog run "chemin/vers/collection.json" -e "id-environnement"

Pour GitHub Actions, une étape de workflow pourrait ressembler à ceci :

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

Pour Jenkins, ajoutez une étape shell à votre pipeline qui appelle l'interface de ligne de commande Apidog. Aucune installation ReadyAPI n'est requise sur l'agent de build.

Mettez à jour vos fichiers de configuration CI pour utiliser la nouvelle commande. Supprimez les références au testrunner ReadyAPI une fois que les exécutions Apidog sont validées correctement.

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

Ne passez pas de ReadyAPI à Apidog en une seule journée. Exécutez les deux outils en parallèle pendant au moins un cycle de publication.

Pendant la période parallèle :

Exécutez les tests ReadyAPI dans la CI comme porte de test faisant autorité.
Exécutez les tests Apidog en parallèle et comparez les résultats.
Recherchez les échecs dans Apidog qui n'apparaissent pas dans ReadyAPI.
Ajoutez progressivement de nouveaux cas de test uniquement dans Apidog.

Une fois que vous êtes confiant qu'Apidog détecte les mêmes échecs que ReadyAPI, retirez ReadyAPI du pipeline CI. Conservez l'installation de ReadyAPI disponible pendant quelques mois en cas de besoin.

FAQ

Combien de temps prend généralement une migration de ReadyAPI vers Apidog ?Un projet REST uniquement avec un script Groovy minimal peut migrer en un à trois jours. Un grand projet avec des scripts Groovy étendus, des cas de test SOAP et des structures de test complexes peut prendre de deux à six semaines. L'audit de l'Étape 1 vous donne l'estimation la plus claire avant de vous engager.

Mes fichiers de données de test ReadyAPI fonctionneront-ils dans Apidog ?Les fichiers de données CSV fonctionnent avec la fonctionnalité de tests basés sur les données d'Apidog. Le format d'importation est similaire. Les fichiers Excel nécessitent une conversion en CSV au préalable. Les fichiers de données XML doivent être restructurés en fonction de la manière dont ils étaient utilisés dans ReadyAPI.

Puis-je exécuter ReadyAPI et Apidog dans le même pipeline CI pendant la migration ?Oui, et c'est l'approche recommandée. Ajoutez l'étape de l'interface de ligne de commande Apidog à votre pipeline existant, parallèlement à l'étape du testrunner ReadyAPI. Comparez les résultats exécution par exécution pendant la période de transition.

Dois-je recréer les environnements manuellement ou existe-t-il un moyen automatisé ?La configuration de l'environnement doit être recréée manuellement dans Apidog. Il n'y a pas d'importation automatisée des paramètres d'environnement ReadyAPI. Gardez vos environnements ReadyAPI ouverts dans une fenêtre pendant que vous les recréez dans Apidog.

Qu'advient-il des tests ReadyAPI qui n'ont pas d'équivalent REST ?Pour les cas de test SOAP uniquement sans alternative REST, les options pratiques sont de maintenir ReadyAPI (éventuellement avec moins de licences) pour ces tests spécifiques, de migrer vers SoapUI Open Source, ou d'accepter une lacune de test si les services sont hérités et à faible risque.

Apidog prend-il en charge les mêmes types d'assertions que ReadyAPI ?Apidog prend en charge les assertions JavaScript qui peuvent exprimer les mêmes conditions logiques que les types d'assertions intégrés de ReadyAPI. La syntaxe est différente mais les capacités sont comparables pour les tests REST. Certains types d'assertions spécifiques à ReadyAPI (erreur SOAP, WS-Security) n'ont pas d'équivalent Apidog.

La migration de ReadyAPI vers Apidog est un projet significatif, pas une tâche d'une après-midi. Les équipes qui la planifient soigneusement, commencent par un audit clair, migrent d'abord les cas de test REST et exécutent les deux outils en parallèle pendant la transition la terminent sans lacunes de couverture ni régressions de test.