WebDriver BiDi: Cara Kerja Otomatisasi Browser Berbasis Event

Pengujian browser otomatis membantu tim memastikan halaman web tetap bekerja setelah perubahan kode. WebDriver tradisional menggunakan pola perintah dan respons: alat pengujian mengirim perintah ke browser, lalu menunggu hasilnya. WebDriver BiDi (Bidirectional WebDriver) memperluas pendekatan itu dengan komunikasi dua arah, sehingga browser juga dapat mengirim peristiwa kepada klien otomatisasi. Model berbasis peristiwa ini berguna ketika tes perlu mengamati navigasi, perubahan konteks, pesan log, atau aktivitas jaringan tanpa terus-menerus menanyakan keadaan browser. Untuk pengujian antarmuka otomatis, baca panduan visual regression testing dan rujuk spesifikasi WebDriver BiDi dari W3C.

WebDriver BiDi bukan pengganti universal untuk semua alat otomasi browser. Ia merupakan protokol yang berkembang dan dukungan fitur dapat berbeda antar-browser serta library. Spesifikasi W3C yang tersedia saat artikel ini ditulis berstatus Working Draft, sehingga implementasi harus diuji pada versi browser dan alat yang benar-benar dipakai.

Apa Itu WebDriver BiDi?

WebDriver adalah protokol lintas platform untuk mengendalikan browser dari perangkat lunak pengujian. Klien mengirim perintah ke remote end, biasanya browser atau server perantara, lalu menerima respons. WebDriver BiDi menambahkan kanal komunikasi dua arah yang memungkinkan klien berlangganan peristiwa yang berasal dari browser. Dengan begitu, otomasi bisa bereaksi terhadap kejadian saat kejadian itu berlangsung.

BiDi umumnya menggunakan koneksi WebSocket untuk komunikasi pesan. Pesan perintah memiliki ID sehingga respons dapat dipasangkan dengan permintaan yang benar, sedangkan pesan peristiwa dikirim ketika peristiwa yang telah didaftarkan terjadi. Detail protokol dan nama perintah mengikuti spesifikasi serta dukungan implementasi yang dipilih.

Bagaimana Alur Kerjanya?

1. Klien membuka sesi. Library otomasi membangun sesi dengan browser atau endpoint remote yang mendukung WebDriver BiDi.
2. Klien mengirim perintah. Contohnya membuat konteks browsing, menavigasi halaman, atau mendaftarkan langganan peristiwa.
3. Browser mengirim respons dan event. Respons menjelaskan hasil perintah; event melaporkan kejadian seperti perubahan navigasi, log, atau aktivitas lain yang didukung.
4. Test runner menghubungkan event ke pemeriksaan. Tes dapat menunggu event yang relevan, memeriksa detailnya, lalu mengambil keputusan tanpa polling yang berlebihan.
5. Sesi ditutup dengan bersih. Langganan, konteks sementara, dan koneksi diakhiri agar satu tes tidak mencemari tes berikutnya.

Contohnya, sebuah tes ingin memastikan bahwa klik tombol mengarahkan pengguna ke halaman konfirmasi. Dengan pola berbasis event, test runner dapat memasang penantian terhadap navigasi terlebih dahulu, menjalankan klik, lalu memeriksa URL dan isi halaman setelah event yang sesuai diterima. Detail API persisnya bergantung pada library yang digunakan; contoh konseptual ini bukan kode siap salin untuk semua driver.

Perbedaan WebDriver Klasik dan BiDi

Keduanya tidak harus diperlakukan sebagai pilihan yang saling meniadakan. Banyak framework mengabstraksikan detail protokol dan menyediakan API tingkat tinggi. Tim sebaiknya memilih berdasarkan fitur yang tersedia, kebutuhan test suite, stabilitas driver, dan kemudahan diagnosis kegagalan.

Contoh Penggunaan

• Memantau navigasi. Tes dapat mengamati peralihan halaman dan memverifikasi bahwa navigasi yang diharapkan terjadi, bukan hanya mengandalkan penundaan tetap.
• Mengumpulkan log browser. Event log yang didukung dapat membantu menemukan error JavaScript yang terjadi selama skenario pengujian.
• Mengamati aktivitas jaringan. Pada implementasi yang mendukung event terkait, tes dapat menghubungkan permintaan atau respons jaringan dengan tindakan pengguna.
• Menangani banyak konteks. Otomasi yang mengelola tab atau konteks browsing memerlukan pemetaan event yang benar agar kejadian dari tab lain tidak dianggap berasal dari tes saat ini.
• Mendiagnosis tes flaky. Menunggu kondisi atau event yang tepat biasanya lebih andal daripada menambahkan jeda beberapa detik tanpa mengetahui kapan browser siap.

Praktik Implementasi yang Lebih Andal

Pastikan dukungan fitur

Periksa status dukungan untuk browser, versi browser, driver, dan library otomasi yang digunakan. Jangan menyimpulkan sebuah fitur tersedia hanya karena koneksi BiDi berhasil dibuat; perintah atau domain event tertentu mungkin belum didukung, dibatasi, atau berubah antarversi.

Gunakan penantian berbasis kondisi

Hindari jeda tetap ketika test runner dapat menunggu event atau kondisi halaman. Tetapkan batas waktu yang realistis, berikan pesan kegagalan yang jelas, dan bedakan antara event tidak pernah muncul, event datang dengan data tak terduga, dan browser gagal menjalankan perintah.

Isolasi sesi dan konteks

Setiap tes perlu memiliki konteks atau sesi yang bersih sesuai kemampuan framework. Lepaskan langganan event, tutup koneksi, dan tangani kegagalan di blok pembersihan. Tanpa isolasi, event lama bisa memengaruhi hasil tes berikutnya.

Perhatikan keamanan endpoint remote

Endpoint yang memungkinkan kendali browser harus diperlakukan sebagai akses istimewa. Jangan membuka port otomasi ke jaringan publik tanpa autentikasi dan pembatasan yang kuat. Gunakan jaringan terisolasi, kontrol akses, serta kredensial atau token yang tidak dicetak ke log. Sesi browser otomatis dapat mengakses akun yang sedang masuk, cookie, dan data sensitif.

Catat bukti yang berguna

Saat tes gagal, simpan langkah yang dilakukan, jenis event yang dinantikan, batas waktu, URL terakhir, dan cuplikan log yang aman. Hindari menyimpan cookie, token, data pribadi, atau isi formulir rahasia dalam log artefak pengujian.

Batasan yang Perlu Dipahami

WebDriver BiDi masih berkembang dan tidak setiap event atau command tersedia seragam di semua implementasi. Event juga dapat datang dalam urutan yang berbeda dari asumsi tes bila skenario tidak dirancang secara tepat. Klien perlu membedakan event untuk konteks atau navigasi tertentu serta menghindari ketergantungan pada urutan yang tidak dijamin oleh protokol.

BiDi juga tidak otomatis menjadikan pengujian lebih cepat. Kecepatan dan stabilitas tetap bergantung pada desain tes, jumlah sesi, lingkungan CI, kondisi jaringan, waktu pemuatan halaman, serta cara test runner menunggu kondisi. Mulailah dengan satu skenario yang benar-benar membutuhkan event, lalu bandingkan keandalan dan kemudahan debugging sebelum memperluas penggunaan.

Checklist Sebelum Digunakan di CI

• Pastikan browser dan driver mendukung fitur BiDi yang diperlukan.
• Uji tes di lingkungan lokal dan CI dengan versi browser yang dikunci.
• Gunakan wait berbasis event atau kondisi dengan timeout dan pesan kegagalan yang jelas.
• Pastikan event terkait dengan konteks/tab yang benar.
• Bersihkan langganan dan sesi setelah tes selesai.
• Batasi akses ke endpoint browser remote dan lindungi artefak log.
• Dokumentasikan fitur yang masih eksperimental atau memiliki dukungan parsial.

Kesimpulan

WebDriver BiDi membawa model komunikasi dua arah ke otomasi browser, sehingga test runner dapat bereaksi terhadap peristiwa yang dikirim browser. Pendekatan ini sangat berguna untuk observasi navigasi, log, dan aktivitas lain yang didukung protokol. Manfaat terbesar datang dari penantian berbasis kondisi, isolasi sesi, serta diagnostik yang baik—bukan sekadar mengganti satu protokol dengan protokol lain. Karena spesifikasi dan dukungan implementasi terus berkembang, validasi terhadap browser dan library aktual tetap menjadi langkah wajib.

Sumber resmi: Spesifikasi W3C WebDriver BiDi dan Spesifikasi W3C WebDriver. Spesifikasi BiDi yang ditautkan berstatus Working Draft dan dapat berubah.