SOAP belum hilang. Sistem perbankan, *gateway* pembayaran, layanan pemerintah, dan platform perusahaan yang lebih lama masih mengekspos *endpoint* SOAP, dan seseorang harus mengujinya. Jika Anda menghabiskan karier Anda di REST dan JSON, layanan SOAP bisa terasa asing. Protokolnya lebih ketat, *payload*-nya adalah XML, dan kontraknya berada dalam file WSDL terpisah.
Kabar baiknya adalah menguji API SOAP secara online tidak sulit setelah Anda memahami apa yang sebenarnya diinginkannya dari Anda. Panduan ini menjelaskan bagaimana pengujian SOAP berbeda dari pengujian REST, menelusuri permintaan nyata, dan mencakup alat online yang menangani SOAP tanpa menyulitkan Anda.
Mengapa pengujian SOAP berbeda
REST adalah gaya. SOAP adalah protokol dengan aturan. Perbedaan itu membentuk segala sesuatu tentang cara Anda mengujinya.
Pesan SOAP selalu berupa dokumen XML yang dibungkus dalam sebuah *envelope*. *Envelope* tersebut memiliki *header* untuk metadata seperti otentikasi atau perutean, dan sebuah *body* yang berisi operasi sebenarnya serta parameternya. Anda tidak bisa hanya mengirim objek JSON yang longgar. Strukturnya wajib, dan *envelope* yang salah format akan ditolak sebelum logika Anda berjalan. SOAP juga hampir selalu berjalan melalui HTTP POST, bahkan untuk operasi yang hanya membaca data, dan ia mengharapkan Content-Type tertentu, biasanya text/xml atau application/soap+xml.
Perbedaan praktis terbesar adalah WSDL. Sebuah WSDL, atau file Web Services Description Language, adalah kontrak yang dapat dibaca mesin yang mencantumkan setiap operasi yang ditawarkan layanan, bentuk pasti dari setiap permintaan dan respons, serta alamat *endpoint*. REST jarang sekali menyediakan sesuatu yang seketat ini. Saat Anda menguji SOAP, WSDL adalah peta Anda. Penguji SOAP online yang baik akan membaca WSDL dan membuat templat permintaan untuk Anda, sehingga Anda tidak mengetik *envelope* secara manual dari ingatan. Jika Anda ingin gambaran kontrak yang lebih luas, catatan kami tentang pengujian kontrak API menjelaskan mengapa kontrak yang ketat adalah aset.
Seperti apa sebenarnya permintaan SOAP itu
Berikut adalah permintaan SOAP yang realistis terhadap layanan konversi mata uang. Perhatikan *envelope*, deklarasi *namespace*, dan operasi yang tersarang di dalam *body*.
POST /CurrencyService.asmx HTTP/1.1
Host: rates.example.com
Content-Type: text/xml; charset=utf-8
SOAPAction: "https://rates.example.com/ConvertAmount"
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:cur="https://rates.example.com/">
<soap:Header>
<cur:AuthToken>e9f2a1c7-4b8d-4c2a-9f31-7d6e5a4b3c21</cur:AuthToken>
</soap:Header>
<soap:Body>
<cur:ConvertAmount>
<cur:FromCurrency>USD</cur:FromCurrency>
<cur:ToCurrency>EUR</cur:ToCurrency>
<cur:Amount>250.00</cur:Amount>
</cur:ConvertAmount>
</soap:Body>
</soap:Envelope>
Respons dikembalikan dengan cara yang sama:
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:cur="https://rates.example.com/">
<soap:Body>
<cur:ConvertAmountResponse>
<cur:ConvertAmountResult>231.45</cur:ConvertAmountResult>
</cur:ConvertAmountResponse>
</soap:Body>
</soap:Envelope>
Dua detail yang sering membingungkan orang. *Header* HTTP SOAPAction diwajibkan oleh banyak layanan dan harus sesuai dengan operasi, atau Anda akan mendapatkan *fault*. Dan ketika terjadi kegagalan, SOAP tidak mengembalikan HTTP 400 dengan pesan yang rapi. Ia mengembalikan HTTP 200 dengan elemen <soap:Fault> di dalam *body*. Pengujian Anda harus mengurai *body* untuk mengetahui apakah panggilan benar-benar berhasil. Memeriksa kode status saja tidak cukup, itulah salah satu alasan mengapa assertions API terstruktur lebih penting di sini daripada di REST.
Alat online untuk menguji API SOAP
Apidog
Apidog menangani SOAP bersama REST, GraphQL, dan WebSocket di satu tempat. Anda mengimpor WSDL, dan ia menghasilkan struktur permintaan sehingga Anda tidak perlu membuat *envelope* secara manual. Anda dapat menambahkan *assertions* pada elemen XML, merangkai permintaan ke dalam skenario, dan menjalankan keseluruhannya sebagai *suite* otomatis. Karena ia juga merancang dan melakukan *mock* API, Anda dapat melakukan *mock* respons SOAP sebelum layanan yang sebenarnya siap. Unduh Apidog untuk menguji layanan SOAP pada *tier* gratis.
SoapUI
SoapUI adalah alat pengujian SOAP asli dan masih yang terdalam. Arahkan ke WSDL dan ia akan membangun proyek dengan setiap operasi. Edisi *open-source* gratis dan kuat untuk pengujian SOAP fungsional dan berbasis data. Ini adalah aplikasi desktop Java yang lebih berat, dan fitur pelaporan paling canggih berada di *tier* ReadyAPI berbayar. Untuk melihat lebih dekat, lihat apa itu SoapUI dan bagaimana cara kerjanya.
Postman
Postman dapat mengirim permintaan SOAP. Anda mengatur *body* ke XML mentah, menambahkan *header* Content-Type dan SOAPAction secara manual, dan menempelkan *envelope* Anda. Ini berfungsi, tetapi Postman tidak mengurai WSDL, jadi Anda harus membuat *envelope* sendiri. Ini baik untuk pemeriksaan sekali jalan dan kurang nyaman untuk permukaan SOAP yang besar.
Penguji SOAP berbasis *browser*
Beberapa alat web ringan memungkinkan Anda menempelkan URL WSDL dan mengirim permintaan dari tab *browser*. Mereka berguna untuk verifikasi cepat tanpa perlu menginstal apa pun. Batasan-batasannya terlihat cepat: dukungan *assertion* yang tipis, sedikit atau tanpa otomatisasi, dan tidak ada cara untuk mengatur *test suite* yang sebenarnya. Gunakan mereka untuk mengonfirmasi *endpoint* hidup, bukan untuk membangun *regression suite*.
Alur kerja pengujian SOAP singkat
- Dapatkan WSDL. Kebanyakan layanan SOAP mengeksposnya dengan menambahkan
?wsdlke URL *endpoint*. Buka dan konfirmasi bahwa ia memuat. - Impor WSDL ke alat Anda. Apidog dan SoapUI menghasilkan templat permintaan dari sana. Ini adalah penghemat waktu terbesar.
- Isi parameter operasi. Gunakan nilai sebenarnya. Uji konversi mata uang dengan jumlah aktual dan kode mata uang yang valid.
- Atur *header*. Konfirmasi
Content-Typedan, jika diperlukan,SOAPAction.SOAPActionyang hilang adalah penyebab paling umum dari *fault* yang tidak dapat dijelaskan. - Kirim dan periksa *body*. Jangan berhenti pada status HTTP. Buka *response body* dan cari
<soap:Fault>. - Tambahkan *assertions*. Nyatakan bahwa elemen tertentu ada dan menyimpan nilai yang diharapkan. Kemudian rangkai panggilan tindak lanjut jika alur Anda memerlukannya.
Untuk mengaturnya menjadi satu set yang dapat dipelihara, panduan kami tentang membangun *test suites* untuk otomatisasi API berlaku langsung untuk pekerjaan SOAP.
Fault SOAP dan cara melakukan *assertion* padanya
*Fault* SOAP adalah struktur kesalahan protokol. Ia membawa faultcode, faultstring, dan terkadang elemen detail. Karena ia tiba dengan HTTP 200, pengujian yang hanya memeriksa status akan lulus pada panggilan yang gagal. Itu adalah *false positive* yang diam dan berbahaya.
Tulis *assertions* SOAP Anda untuk melihat ke dalam *body*. Nyatakan bahwa tidak ada elemen <soap:Fault> yang ada pada jalur keberhasilan. Pada jalur kesalahan yang disengaja, nyatakan sebaliknya, bahwa *fault* muncul dan faultcode cocok dengan yang Anda harapkan. Menguji kasus kegagalan sama pentingnya dengan *happy path*, karena layanan SOAP sering kali mengkodekan aturan bisnis, seperti transaksi yang ditolak, sebagai *fault* daripada data. Dokumentasi *fault* SOAP W3C menjelaskan strukturnya jika Anda membutuhkan detail formal.
WS-Security menambahkan lapisan lain. Banyak layanan SOAP perusahaan mengharapkan *header* keamanan yang ditandatangani atau membawa token. Jika permintaan Anda gagal dengan *authentication fault*, WSDL atau dokumen layanan akan menyatakan profil keamanan mana yang digunakan. Alat seperti SoapUI dan Apidog memungkinkan Anda mengonfigurasi *header* ini daripada membuat XML secara manual.
Membaca WSDL tanpa tersesat
File WSDL terlihat mengintimidasi saat pertama kali Anda membukanya. Ini adalah XML yang panjang, bersarang dalam, dan sebagian besar adalah *plumbing* mesin. Anda tidak perlu membaca semuanya. Empat bagian membawa informasi yang sebenarnya Anda inginkan.
Bagian types mendefinisikan struktur data, biasanya sebagai Skema XML, jadi di sinilah Anda mempelajari bentuk dan batasan pasti dari setiap parameter. Elemen message menjelaskan input dan output untuk setiap operasi. portType mencantumkan operasi itu sendiri, yang merupakan panggilan yang dapat Anda buat. Bagian service dan binding memberikan alamat *endpoint* konkret dan detail transport. Ketika Anda mengimpor WSDL ke dalam alat, ia membaca keempatnya dan mengubahnya menjadi permintaan yang siap diedit, itulah mengapa mengimpor selalu lebih baik daripada mengetik manual.
Satu detail yang perlu diketahui: WSDL dapat terbagi di beberapa file menggunakan pernyataan import, seringkali menarik skema dari lokasi terpisah. Jika alat Anda melaporkan tipe yang hilang, file yang direferensikan mungkin gagal diselesaikan. Pastikan setiap URL yang diimpor dapat dijangkau dari tempat alat Anda berjalan. Jenis dependensi kontrak ini persis mengapa tim memperlakukan WSDL sebagai artefak berversi daripada sesuatu yang hanya ada di server.
Pengujian SOAP berbasis data
Layanan SOAP sering kali membawa aturan bisnis yang ketat, dan satu permintaan *happy-path* jarang membuktikan banyak hal. Layanan mata uang harus diuji dengan pasangan yang valid, dengan mata uang yang tidak didukung, dengan jumlah nol, dan dengan jumlah negatif. Layanan pembayaran harus diuji dengan kartu yang disetujui, kartu yang ditolak, dan kartu yang kedaluwarsa. Mengetik setiap ini secara manual lambat dan mudah salah.
Pengujian berbasis data mengatasi hal ini. Anda menulis permintaan sekali dengan *placeholder*, lalu memberinya tabel baris input dan hasil yang diharapkan. Alat tersebut menjalankan permintaan untuk setiap baris dan memeriksa setiap hasil. SoapUI telah mendukung pola ini selama bertahun-tahun, dan Apidog mendukungnya melalui *scenario runner*-nya. Keuntungannya adalah cakupan nyata dari kasus-kasus ekstrem yang cenderung dikodekan layanan SOAP sebagai *fault*. Untuk pola yang lebih luas, panduan kami tentang pengujian API berbasis data dengan CSV dan JSON menjelaskan cara menyusun data input, dan ini berlaku untuk SOAP sama seperti untuk REST.
Pertanyaan yang Sering Diajukan
Apa perbedaan antara pengujian SOAP dan REST?
Pengujian SOAP bekerja melawan protokol XML yang ketat dengan kontrak WSDL, *envelope* wajib, dan *fault* yang dikembalikan di dalam *body* HTTP 200. Pengujian REST biasanya berurusan dengan JSON, konvensi yang lebih longgar, dan kode status HTTP yang bermakna. Pengujian SOAP harus mengurai *response body* untuk mengonfirmasi keberhasilan; pengujian REST seringkali dapat mempercayai kode status.
Apakah saya memerlukan WSDL untuk menguji API SOAP?
Anda dapat mengirim permintaan SOAP tanpanya jika Anda sudah mengetahui struktur *envelope* yang tepat. Tetapi WSDL membuat pengujian jauh lebih mudah karena alat menghasilkan templat permintaan yang benar darinya. Kebanyakan layanan mengekspos WSDL dengan menambahkan ?wsdl ke URL *endpoint*. Selalu mulai dari sana.
Mengapa permintaan SOAP saya mengembalikan *fault* meskipun statusnya 200?
SOAP melaporkan kesalahan sebagai elemen <soap:Fault> di dalam *body*, bukan sebagai kode kesalahan HTTP, jadi status 200 dengan *fault* adalah normal. Penyebab umum adalah *header* SOAPAction yang hilang atau salah, *envelope* yang salah format, ketidakcocokan *namespace*, atau pemeriksaan keamanan yang gagal. Baca faultstring untuk alasan spesifiknya.
Bisakah saya menguji API SOAP secara online secara gratis?
Ya. Apidog mendukung SOAP pada tingkatan gratisnya dan mengimpor file WSDL, dan edisi *open-source* SoapUI dibangun untuk SOAP. Penguji *browser* ringan juga ada untuk pemeriksaan cepat, meskipun mereka tidak memiliki dukungan *assertion* dan otomatisasi yang nyata.
Bagaimana cara mengotomatiskan pengujian API SOAP?
Impor WSDL, bangun skenario yang merangkai operasi secara berurutan, tambahkan *assertions* pada elemen respons dan pada ketiadaan *fault*, lalu jalankan dari *runner* alat atau di *pipeline* CI Anda. SoapUI dan Apidog keduanya mendukung *suite* SOAP yang dijadwalkan dan dipicu *pipeline*, jadi *regression run* SOAP cocok dengan alur otomatisasi yang sama seperti REST.