Selenium untuk Uji API: Bisakah dan Haruskah?

Selenium adalah kerangka kerja otomatisasi browser. Ini menggerakkan Chrome, Firefox, dan browser lain sebagaimana mestinya seseorang: mengklik tombol, mengisi formulir, membaca halaman yang dirender. Ini adalah alat standar untuk pengujian UI end-to-end, dan sangat bagus dalam pekerjaannya.

Orang-orang masih bertanya apakah Selenium dapat menguji API. Jawaban jujur adalah bahwa Anda bisa membuatnya mengeluarkan panggilan HTTP, tetapi itu adalah alat yang salah untuk pekerjaan itu. Panduan ini menjelaskan dengan tepat mengapa, menunjukkan seperti apa pengujian API melalui Selenium, dan mengarahkan Anda ke alat yang memang dibangun untuk pekerjaan itu. Tujuannya adalah untuk menyelamatkan Anda dari pengaturan yang akan membuat Anda frustasi nanti.

Mengapa Selenium dan Pengujian API Tidak Cocok

Sebuah tes API mengirimkan permintaan HTTP langsung ke server dan memeriksa responsnya: kode status, header, body, waktu. Tidak ada antarmuka pengguna yang terlibat. Tes harus cepat, terisolasi, dan murah untuk dijalankan ribuan kali.

Selenium justru melakukan sebaliknya berdasarkan desain. Ia meluncurkan browser sungguhan, memuat halaman, dan menunggu JavaScript dirender. Browser itu adalah inti keseluruhan saat Anda menguji UI, dan merupakan beban tambahan murni saat Anda menguji API. Permintaan yang dikirim oleh klien khusus dalam puluhan milidetik menjadi urusan multi-detik setelah Anda melibatkan proses browser, sesi WebDriver, dan rendering halaman.

Ada juga ketidakcocokan yang lebih dalam. Seluruh API Selenium adalah tentang elemen di halaman: temukan tombol ini, baca teks ini, tunggu elemen ini. Respons HTTP bukanlah halaman. Ia tidak memiliki DOM. Jadi Selenium tidak memberikan apa pun yang berguna bagi Anda untuk memeriksa body JSON, melakukan assertion pada header, atau memeriksa kode status. Anda akhirnya bekerja memutar balik alat tersebut alih-alih menggunakannya secara langsung.

Biayanya bukan hanya kecepatan. Tes berbasis browser terkenal tidak stabil (flaky). Mereka gagal karena halaman membutuhkan waktu lebih lama untuk dirender, karena sesi WebDriver terputus, atau karena pembaruan browser mengubah beberapa waktu. Tes API harus deterministik: permintaan yang sama menghasilkan respons yang sama, dan kegagalan berarti ada sesuatu yang benar-benar rusak. Mengarahkan pemeriksaan API melalui Selenium membawa semua ketidakstabilan browser itu ke lapisan yang sama sekali tidak punya alasan untuk tidak stabil. Seiring waktu, rangkaian tes yang tidak stabil melatih tim untuk mengabaikan build yang merah, yang mengalahkan tujuan pengujian. Perbedaan antara validasi dan verifikasi adalah sudut pandang yang baik di sini: Selenium memverifikasi pengalaman yang dirender, sementara pengujian API memvalidasi kontrak di bawahnya.

Apa Arti Sebenarnya “Pengujian API dengan Selenium”

Ketika artikel mengklaim Selenium dapat menguji API, mereka biasanya mengacu pada salah satu dari dua solusi. Keduanya tidak membuat Selenium menjadi alat pengujian API. Mereka hanya mengarahkan HTTP melalui atau di sampingnya.

Opsi satu: gunakan eksekutor JavaScript Selenium. Selenium dapat menjalankan JavaScript arbitrer di browser yang dikontrolnya. Browser modern memiliki API fetch, sehingga Anda dapat meminta browser untuk membuat permintaan dan mengembalikan hasilnya ke kode pengujian Anda:

JavascriptExecutor js = (JavascriptExecutor) driver;
Object status = js.executeAsyncScript(
    "const callback = arguments[arguments.length - 1];" +
    "fetch('https://jsonplaceholder.typicode.com/users/1')" +
    "  .then(r => callback(r.status))" +
    "  .catch(e => callback('error: ' + e));"
);
System.out.println("Status code: " + status);

Ini berfungsi. Ini juga berarti Anda telah memulai browser, WebDriver, dan jembatan JavaScript murni hanya untuk membuat satu panggilan HTTP yang akan dilakukan langsung oleh klien HTTP biasa. Anda juga mewarisi batasan browser seperti CORS, yang tidak pernah perlu dipikirkan oleh tes API server-ke-server.

Opsi dua: abaikan Selenium dan gunakan pustaka HTTP sungguhan di sampingnya. Dalam proyek Java, ini berarti memasangkan Selenium dengan REST Assured untuk bagian API:

import static io.restassured.RestAssured.given;
import static org.hamcrest.Matchers.equalTo;

given()
    .when()
    .get("https://jsonplaceholder.typicode.com/users/1")
    .then()
    .statusCode(200)
    .body("email", equalTo("Sincere@april.biz"));

Perhatikan bahwa pengujian API yang sebenarnya di sini sepenuhnya dilakukan oleh REST Assured. Selenium tidak berkontribusi apa pun. Kedua pustaka ini kebetulan berada dalam proyek yang sama. Itu tidak masalah, tetapi ini bukan “pengujian API dengan Selenium.” Ini adalah pengujian API dengan pustaka pengujian API yang tepat, dengan Selenium hadir untuk tes UI yang tidak terkait.

Kapan Menggabungkan Keduanya Masuk Akal

Ada satu kasus yang sah untuk pekerjaan HTTP di dalam rangkaian Selenium, dan penting untuk memperjelasnya. Tes UI Selenium seringkali membutuhkan pengaturan atau pembersihan yang lebih cepat dilakukan melalui API daripada melalui browser.

Misalnya Anda memiliki tes UI yang memeriksa halaman riwayat pesanan. Untuk mengujinya, sebuah pesanan harus ada. Mengklik seluruh alur checkout di browser hanya untuk membuat pesanan itu lambat dan rapuh. Sebaliknya, tes Anda membuat panggilan API langsung untuk membuat pesanan, lalu menggunakan Selenium hanya untuk bagian yang benar-benar membutuhkan browser: memuat halaman riwayat dan memverifikasi pesanan muncul.

Itu adalah praktik yang baik. Panggilan API adalah sarana untuk mencapai tujuan, bukan hal yang diuji. Panggilan API seharusnya tetap melalui klien HTTP sungguhan, bukan eksekutor JavaScript. Jadi, bahkan dalam kasus ini, Selenium tidak melakukan pengujian API. Ia melakukan pengujian UI, dan klien HTTP yang tepat menangani sisi API.

Pola `setup-over-API` ini cukup umum sehingga sebagian besar rangkaian tes yang matang mengadopsinya secara sengaja. Ini menjaga bagian rangkaian yang lambat dan didorong browser sekecil mungkin, dicadangkan untuk beberapa perjalanan yang benar-benar membutuhkan halaman yang dirender. Semua yang lain, termasuk semua persiapan data dan sebagian besar verifikasi, terjadi melalui panggilan HTTP cepat. Hasilnya adalah rangkaian tes yang berjalan dalam hitungan menit alih-alih jam dan gagal karena alasan yang nyata. Untuk gambaran yang lebih luas tentang bagaimana UI dan lapisan otomatisasi menyatu, lihat pengujian fungsional versus pengujian otomatis.

Gunakan Alat yang Dibangun untuk Pengujian API

Jika tujuan Anda adalah menguji API, gunakan sesuatu yang dirancang untuk itu. Perbedaannya tidak kecil. Alat pengujian API yang nyata memberi Anda pembuatan permintaan, manajemen lingkungan, assertions pada status, header, dan body, penggabungan permintaan, eksekusi berbasis data, dan integrasi CI, tanpa meluncurkan browser.

Pilihan Anda terbagi dalam beberapa kelompok:

Jika Anda lebih suka kode, pustaka HTTP seperti REST Assured di Java, requests di Python, atau supertest di Node adalah pilihan yang tepat. Pustaka ini membuat permintaan dan mengembalikan respons langsung kepada Anda, dengan pembantu assertion yang dibangun untuk kode status dan body JSON. Tidak ada browser, tidak ada WebDriver, dan tidak ada rendering, sehingga rangkaian lengkap berjalan cepat dan gagal hanya ketika API itu sendiri berubah.

Jika Anda menginginkan ruang kerja visual, Apidog adalah platform API all-in-one yang mencakup perancangan API, debug permintaan, mocking endpoint, membangun skenario tes otomatis, dan menghasilkan dokumentasi, semuanya dalam satu proyek. Anda membangun assertions secara visual atau dengan skrip, merangkai permintaan menjadi alur multi-langkah, menjalankan iterasi berbasis data, dan mengeksekusi semuanya di CI. Ini juga mengimpor file OpenAPI dan Postman, sehingga API yang ada cepat untuk dibawa masuk. Tidak ada bagian dari ini yang melibatkan browser, karena memang seharusnya tidak. Anda dapat mengunduh Apidog untuk mencobanya pada API sungguhan.

Untuk tim yang menginginkan kerangka kerja yang mengutamakan kode, panduan tentang Robot Framework untuk otomatisasi API dan membangun kerangka kerja pengujian otomatisasi API mencakup pendekatan yang, tidak seperti Selenium, sebenarnya cocok untuk pengujian HTTP.

Poin Utama yang Jujur

Selenium adalah perangkat lunak yang sangat baik untuk tujuan pembuatannya, yaitu mengotomatisasi browser. Pengujian API bukanlah itu. Secara teknis Anda dapat mendorong HTTP melalui eksekutor JavaScript Selenium, dan Anda dapat menyimpan pustaka HTTP dalam proyek yang sama dengan Selenium, tetapi dalam kedua kasus tersebut Selenium tidak menambah nilai pada pengujian API itu sendiri.

Memilih alat yang salah bukanlah keputusan yang netral. Itu membuat tes Anda lebih lambat, lebih sulit dirawat, dan rentan terhadap kegagalan yang tidak ada hubungannya dengan API Anda. Raihlah alat yang dibangun untuk pekerjaan itu. Rangkaian tes Anda akan lebih cepat, lebih andal, dan jauh lebih mudah dipahami. Rangkuman platform pengujian otomatis terbaik adalah tempat yang baik untuk membandingkan opsi yang dibangun khusus.

Pertanyaan yang Sering Diajukan

Bisakah Selenium Menguji API REST Sama Sekali?

Ini dapat mengeluarkan permintaan HTTP melalui eksekutor JavaScript browser, jadi dalam arti teknis yang sempit, ya. Tetapi Selenium tidak memiliki fitur untuk memeriksa respons, melakukan assertion pada JSON, atau memeriksa header, dan ia membawa seluruh overhead browser. Ini bukan alat pengujian API REST, dan menggunakannya sebagai salah satunya menciptakan tes yang lambat dan rapuh.

Mengapa Beberapa Tutorial Menampilkan Selenium dengan REST Assured?

Karena pengujian API dalam tutorial tersebut sepenuhnya dilakukan oleh REST Assured, yang merupakan pustaka pengujian HTTP sungguhan. Selenium hanya ada dalam proyek yang sama untuk tes UI yang tidak terkait. Pasangan ini baik-baik saja, tetapi itu tidak berarti Selenium menguji API. REST Assured lah yang melakukannya.

Apakah Boleh Melakukan Panggilan API dalam Tes Selenium?

Ya, untuk pengaturan dan pembersihan. Membuat data tes melalui API lebih cepat dan lebih andal daripada mengklik melalui UI untuk menghasilkannya. Panggilan API mendukung tes UI daripada menjadi hal yang diuji, dan seharusnya tetap menggunakan klien HTTP yang tepat, bukan eksekutor JavaScript Selenium.

Apa yang Harus Saya Gunakan Selain Selenium untuk Pengujian API?

Untuk pengujian yang mengutamakan kode, pustaka HTTP seperti REST Assured, requests Python, atau supertest untuk Node. Untuk ruang kerja visual, platform API khusus seperti Apidog, atau klien seperti Postman, Insomnia, dan Talend API Tester. Semua ini dibangun untuk HTTP dan menghindari overhead browser yang dikenakan Selenium.

Apakah Menggunakan Selenium untuk Tes API Memperlambat Pipeline CI Saya?

Secara signifikan. Setiap panggilan API berbasis Selenium memulai proses browser dan sesi WebDriver, mengubah permintaan HTTP di bawah satu detik menjadi operasi multi-detik. Di seluruh rangkaian, itu menghasilkan eksekusi pipeline yang panjang dan tidak stabil. Alat pengujian API khusus menjalankan pemeriksaan yang sama jauh lebih cepat karena tidak pernah meluncurkan browser.