Cara Migrasi dari ReadyAPI ke Apidog dengan Mudah

TL;DR

Migrasi dari ReadyAPI ke Apidog cukup mudah untuk rangkaian pengujian yang banyak menggunakan REST. Ekspor proyek ReadyAPI Anda, konversi apa yang bisa melalui impor OpenAPI, dan buat ulang skrip Groovy secara manual di JavaScript. Kasus uji SOAP memerlukan pekerjaan manual paling banyak. Rencanakan migrasi bertahap untuk menjaga cakupan pengujian tetap berkelanjutan.

💡

Apidog adalah platform pengembangan API lengkap gratis yang mengimpor spesifikasi OpenAPI dan koleksi Postman serta menjalankan pipeline pengujian dengan skrip JavaScript. Coba Apidog gratis, tidak diperlukan kartu kredit.

tombol

Pendahuluan

Memigrasikan infrastruktur pengujian API adalah salah satu tugas yang terdengar mudah sampai Anda memulainya. Proyek ReadyAPI dapat berisi kasus uji yang terakumulasi selama bertahun-tahun, skrip Groovy kustom, file data, lingkungan, dan struktur rangkaian uji yang kompleks. Memasukkan semua itu ke Apidog memerlukan pemahaman tentang apa yang ditransfer secara otomatis, apa yang memerlukan konversi manual, dan apa yang mungkin Anda putuskan untuk ditinggalkan.

Panduan ini akan memandu Anda melalui proses migrasi langkah demi langkah. Ini mencakup mengekspor proyek ReadyAPI Anda, menganalisis apa yang Anda miliki, mengimpor ke Apidog, menangani konversi Groovy ke JavaScript, menyiapkan CI/CD, dan mengelola periode transisi ketika kedua alat berjalan secara paralel.

Langkah 1: Audit proyek ReadyAPI Anda sebelum memulai

Sebelum mengekspor apa pun, luangkan waktu untuk memahami apa yang ada dalam proyek ReadyAPI Anda saat ini. Audit ini membentuk berapa lama migrasi akan berlangsung dan di mana Anda akan memfokuskan upaya.

Buka proyek ReadyAPI Anda dan jawab pertanyaan-pertanyaan ini:

Berapa banyak rangkaian pengujian (test suites), kasus pengujian (test cases), dan langkah pengujian (test steps) yang Anda miliki? Buka panel Navigator dan hitung. Proyek dengan 50 kasus pengujian dapat dimigrasikan dalam hitungan jam. Proyek dengan 500 kasus membutuhkan waktu berhari-hari.

Berapa persentase kasus uji REST dibandingkan SOAP? Kasus uji REST bermigrasi jauh lebih bersih. Kasus uji SOAP memerlukan lebih banyak pekerjaan manual, terutama jika mereka menggunakan kebijakan WS-Security atau asersi yang kompleks.

Berapa banyak skrip Groovy yang ada dalam kasus uji Anda? Klik melalui kasus uji Anda dan cari langkah Skrip. Hitung berapa banyak kasus uji yang memiliki logika Groovy kustom. Setiap skrip Groovy memerlukan konversi manual ke JavaScript.

Apakah Anda menggunakan pengujian berbasis data (data-driven tests) dengan langkah DataSource? Apidog mendukung pengujian berbasis data dengan file data CSV dan JSON, tetapi pengaturannya berbeda dari pola DataSource/DataSink ReadyAPI.

Apakah Anda banyak menggunakan langkah Properties atau Property Transfer? Pola-pola ini bekerja secara berbeda di Apidog. Anda akan menggunakan variabel dan variabel lingkungan sebagai gantinya.

Apakah Anda menjalankan pengujian beban (load tests) melalui LoadUI Pro? Integrasi LoadUI Pro tidak terbawa ke Apidog. Anda perlu menyiapkan k6 atau alat pengujian beban lainnya secara terpisah untuk skenario tersebut.

Dokumentasikan temuan Anda. Sebuah spreadsheet dengan nama kasus uji, jenis (REST/SOAP), memiliki-Groovy (ya/tidak), dan kompleksitas (sederhana/menengah/kompleks) akan memberi Anda perkiraan migrasi sebelum Anda memulai.

Langkah 2: Ekspor proyek ReadyAPI Anda

ReadyAPI menyimpan proyek sebagai file XML. Untuk mengekspor proyek untuk analisis:

Buka ReadyAPI dan buka proyek Anda.
Pergi ke File > Save As untuk menyimpan proyek sebagai file XML mandiri.
Simpan semua file data eksternal (CSV, Excel, data uji XML) yang direferensikan oleh pengujian Anda.
Catat konfigurasi lingkungan apa pun yang telah Anda siapkan di bawah bagian Environments.

XML proyek berisi semua rangkaian pengujian, kasus pengujian, langkah pengujian, skrip, dan konfigurasi. Ini adalah representasi lengkap dari proyek pengujian Anda.

Langkah 3: Ekstrak definisi API Anda

Jalur migrasi paling bersih untuk API REST melalui spesifikasi OpenAPI, bukan langsung dari XML proyek ReadyAPI.

Opsi A: Ekspor dari ReadyAPI. Jika Anda memiliki layanan REST di ReadyAPI, klik kanan padanya di Navigator dan cari opsi ekspor atau buat definisi API. ReadyAPI dapat mengekspor spesifikasi Swagger/OpenAPI dari definisi layanan.

Opsi B: Gunakan spesifikasi OpenAPI backend Anda. Jika layanan backend Anda sudah mengekspos spesifikasi OpenAPI (di /openapi.json atau yang serupa), unduh langsung. Ini memberi Anda definisi yang paling akurat dan terkini.

Opsi C: Ekstrak secara manual. Untuk API tanpa spesifikasi yang ada, gunakan permintaan REST ReadyAPI Anda sebagai sumber. Catat endpoint, badan permintaan, header, dan struktur respons. Anda akan membuatnya ulang di Apidog.

Langkah 4: Impor ke Apidog

Dengan spesifikasi OpenAPI Anda siap, impor ke Apidog.

Buka Apidog dan buat proyek baru.
Buka API > Impor dan pilih format Anda (OpenAPI 3.0, Swagger 2.0, dll.).
Unggah file spesifikasi atau tempel URL.
Apidog mengurai spesifikasi dan membuat definisi API untuk semua endpoint.

Setelah impor, Anda memiliki definisi API terstruktur dengan semua endpoint, parameter, badan permintaan, dan skema respons yang terisi. Ini adalah dasar untuk kasus uji Anda.

Jika Anda memiliki koleksi Postman yang ada (mungkin dimigrasikan dari alat sebelumnya), Apidog juga mengimpornya melalui File > Impor > Postman.

Langkah 5: Buat ulang kasus uji untuk endpoint REST

Untuk kasus uji REST, proses migrasinya adalah:

Buka kasus uji REST ReadyAPI.
Identifikasi permintaan, asersi, dan sumber data apa pun yang digunakannya.
Buat kasus uji yang sesuai di Apidog dengan memilih endpoint API dan menambahkan langkah-langkah pengujian.

Asersi diterjemahkan sebagai berikut:

Asersi "Contains" (badan berisi string) menjadi asersi JavaScript: pm.test('contains value', () => { pm.expect(pm.response.text()).to.include('expected string'); });
Asersi kode status: pm.test('status 200', () => { pm.response.to.have.status(200); });
Asersi JSONPath: pm.test('field value', () => { pm.expect(pm.response.json().fieldName).to.equal('expected'); });

Untuk pengujian GET dan POST yang mudah tanpa Groovy, migrasi ini cepat. Kasus uji sederhana dengan 5 hingga 10 asersi dapat dibuat ulang dalam 15 hingga 30 menit.

Langkah 6: Konversi skrip Groovy ke JavaScript

Ini adalah bagian migrasi yang paling padat karya untuk proyek dengan skrip kustom yang signifikan.

Pola Groovy umum dan padanan JavaScript-nya:

Membaca nilai respons:

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

Mengatur variabel:

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

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

Asersi kondisional:

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

Manipulasi tanggal:

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

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

Untuk skrip Groovy kompleks dengan impor pustaka Java atau logika yang rumit, konversi memerlukan analisis yang cermat. Baca setiap skrip, pahami apa yang dilakukannya, dan tulis JavaScript yang setara. Jangan mencoba terjemahan otomatis — semantiknya cukup mirip untuk menipu Anda tetapi cukup berbeda untuk menyebabkan bug tersembunyi.

Langkah 7: Menangani kasus uji SOAP

Kasus uji SOAP adalah bagian paling menantang dari setiap migrasi ReadyAPI. Apidog tidak memiliki alat khusus SOAP, jadi ini memerlukan pendekatan yang berbeda.

Untuk layanan SOAP yang juga mengekspos antarmuka REST (yang semakin umum), migrasikan pengujian untuk menggunakan endpoint REST dan singkirkan lapisan SOAP.

Untuk layanan SOAP tanpa alternatif REST, Anda memiliki dua pilihan:

Pertahankan ReadyAPI hanya untuk SOAP. Jalankan ReadyAPI secara paralel untuk kasus uji SOAP dan gunakan Apidog untuk REST. Ini adalah jalan tengah yang praktis yang menjaga cakupan SOAP tanpa menghalangi migrasi REST.

Gunakan SoapUI Open Source. SoapUI Open Source gratis dan menangani pengujian SOAP. Ini tidak dapat menggantikan semua fitur ReadyAPI, tetapi ini mencakup pengujian fungsional SOAP dasar tanpa biaya lisensi.

Jangan terburu-buru melakukan migrasi SOAP. Kasus uji WS-Security khususnya membawa risiko signifikan jika asersinya tidak direproduksi dengan hati-hati.

Langkah 8: Siapkan lingkungan dan variabel

Fitur Environment ReadyAPI memetakan ke sistem Environment Apidog. Untuk setiap lingkungan ReadyAPI yang telah Anda konfigurasikan:

Buat lingkungan yang cocok di Apidog (Pengaturan > Lingkungan).
Tambahkan variabel yang sama: URL dasar, token otentikasi, header bersama, dll.
Verifikasi bahwa kasus uji mereferensikan variabel dengan sintaks Apidog yang benar: {{variableName}} di bidang URL dan badan permintaan.

Langkah 9: Konfigurasikan CI/CD

Pengaturan CI ReadyAPI biasanya melibatkan perintah testrunner pada agen pembangunan. Apidog menggunakan pendekatan yang berbeda.

Instal Apidog CLI pada agen CI Anda:

npm install -g apidog-cli

Jalankan koleksi pengujian:

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

Untuk GitHub Actions, langkah alur kerja mungkin terlihat seperti:

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

Untuk Jenkins, tambahkan langkah shell ke pipeline Anda yang memanggil Apidog CLI. Tidak diperlukan instalasi ReadyAPI pada agen pembangunan.

Perbarui file konfigurasi CI Anda untuk menggunakan perintah baru. Hapus referensi testrunner ReadyAPI setelah Apidog berjalan memvalidasi dengan benar.

Langkah 10: Jalankan kedua alat secara paralel selama transisi

Jangan beralih dari ReadyAPI ke Apidog dalam satu hari. Jalankan kedua alat secara paralel setidaknya melalui satu siklus rilis.

Selama periode paralel:

Jalankan pengujian ReadyAPI di CI sebagai gerbang pengujian otoritatif.
Jalankan pengujian Apidog secara bersamaan dan bandingkan hasilnya.
Selidiki kegagalan apa pun di Apidog yang tidak muncul di ReadyAPI.
Secara bertahap tambahkan kasus uji baru hanya di Apidog.

Setelah Anda yakin bahwa Apidog menangkap kegagalan yang sama dengan ReadyAPI, hapus ReadyAPI dari pipeline CI. Tetap sediakan instalasi ReadyAPI selama beberapa bulan sebagai cadangan.

FAQ

Berapa lama waktu yang dibutuhkan untuk migrasi dari ReadyAPI ke Apidog?Proyek khusus REST dengan skrip Groovy minimal dapat dimigrasikan dalam satu hingga tiga hari. Proyek besar dengan skrip Groovy yang ekstensif, kasus uji SOAP, dan struktur pengujian yang kompleks dapat memakan waktu dua hingga enam minggu. Audit di Langkah 1 memberi Anda perkiraan paling jelas sebelum Anda berkomitmen.

Apakah file data uji ReadyAPI saya akan berfungsi di Apidog?File data CSV berfungsi dengan fitur pengujian berbasis data Apidog. Format impornya serupa. File Excel memerlukan konversi ke CSV terlebih dahulu. File data XML perlu direstrukturisasi tergantung pada bagaimana file tersebut digunakan di ReadyAPI.

Bisakah saya menjalankan ReadyAPI dan Apidog dalam pipeline CI yang sama selama migrasi?Ya, dan ini adalah pendekatan yang direkomendasikan. Tambahkan langkah Apidog CLI ke pipeline yang ada di samping langkah testrunner ReadyAPI. Bandingkan hasil per-jalankan selama periode transisi.

Apakah saya perlu membuat ulang lingkungan secara manual atau ada cara otomatis?Konfigurasi lingkungan harus dibuat ulang secara manual di Apidog. Tidak ada impor otomatis pengaturan lingkungan ReadyAPI. Biarkan lingkungan ReadyAPI Anda terbuka di satu jendela saat membuatnya ulang di Apidog.

Apa yang terjadi pada pengujian ReadyAPI yang tidak memiliki padanan REST?Untuk kasus uji khusus SOAP tanpa alternatif REST, opsi praktisnya adalah mempertahankan ReadyAPI (mungkin dengan lisensi yang lebih sedikit) untuk pengujian khusus tersebut, bermigrasi ke SoapUI Open Source, atau menerima celah pengujian jika layanan tersebut merupakan layanan lama dan berisiko rendah.

Apakah Apidog mendukung jenis asersi yang sama dengan ReadyAPI?Apidog mendukung asersi JavaScript yang dapat mengekspresikan kondisi logis yang sama dengan jenis asersi bawaan ReadyAPI. Sintaksnya berbeda tetapi kemampuannya sebanding untuk pengujian REST. Beberapa jenis asersi khusus ReadyAPI (SOAP Fault, WS-Security) tidak memiliki padanan di Apidog.

Migrasi dari ReadyAPI ke Apidog adalah proyek yang bermakna, bukan tugas satu sore. Tim yang merencanakannya dengan cermat, memulai dengan audit yang jelas, memigrasikan kasus uji REST terlebih dahulu, dan menjalankan kedua alat secara paralel selama transisi akan menyelesaikannya tanpa celah cakupan atau regresi pengujian.