Kilas balik ke masa lalu: evolusi otomatisasi pengujian

Jecelyn Yeen

Maksim Sadym

Lahir otomatisasi pengujian

Mari kita kembali ke tahun 1990-an ketika browser web lahir. Otomatisasi pengujian tidak terwujud hingga tahun 2000-an, dengan munculnya project Selenium dan WebDriver untuk mengatasi tantangan pengujian lintas browser dan multi-perangkat.

Kedua project ini bergabung pada tahun 2011 sebagai Selenium WebDriver dan menjadi standar W3C pada tahun 2018. Kami biasanya menyebutnya sebagai WebDriver atau WebDriver “Klasik”.

Otomatisasi pengujian sebelum WebDriver “Klasik” cukup rumit. Mampu mengotomatiskan pengujian browser, kualitas kehidupan developer dan penguji meningkat secara signifikan.

Kebangkitan JavaScript

Seiring berkembangnya pengembangan web untuk lebih mengandalkan JavaScript, solusi otomatisasi baru seperti WebdriverIO, Appium, Nightwatch, Protractor (tidak digunakan lagi), Testcafe, Cypress, Puppeteer, dan Playwright juga bermunculan.

Pendekatan otomatisasi

Secara luas, alat ini dapat diatur menjadi dua grup utama berdasarkan cara alat tersebut mengotomatiskan browser:

• Tingkat tinggi: Alat yang menjalankan JavaScript dalam browser. Misalnya, Cypress dan TestCafe memanfaatkan API web dan Node.js untuk menjalankan pengujian langsung di browser. Fakta menarik—versi pertama Selenium juga menggunakan pendekatan yang sama.
• Tingkat rendah: Alat yang menjalankan perintah jarak jauh di luar browser. Saat alat memerlukan kontrol yang lebih besar, seperti membuka beberapa tab atau menyimulasikan mode perangkat, saat itulah alat perlu mengeksekusi perintah jarak jauh untuk mengontrol browser melalui protokol. Dua protokol otomatisasi utama adalah WebDriver “Klasik” dan Chrome DevTools Protocol (CDP).

Di bagian selanjutnya, kita akan melihat kedua protokol ini untuk memahami kekuatan dan keterbatasannya.

WebDriver "Klasik" versus Protokol Chrome DevTools (CDP)

WebDriver "Klasik" adalah standar web yang didukung oleh semua browser utama. Skrip otomatisasi mengeluarkan perintah melalui permintaan HTTP ke server driver, yang kemudian berkomunikasi dengan browser melalui protokol internal khusus browser.

Meskipun memiliki dukungan lintas browser yang sangat baik dan API-nya didesain untuk pengujian, API ini dapat menjadi lambat dan tidak mendukung beberapa kontrol tingkat rendah.

Misalnya, bayangkan Anda memiliki skrip pengujian yang mengklik elemen await coffee.click();. Permintaan ini diterjemahkan menjadi serangkaian permintaan HTTP.

# WebDriver: Click on a coffee element

curl -X POST http://127.0.0.1:4444/session/:element_id/element/click
   -H 'Content-Type: application/json'
   -d '{}'

Di sisi lain, Chrome DevTools Protocol (CDP) awalnya dirancang untuk Chrome DevTools dan proses debug, tetapi diadopsi oleh Puppeteer untuk otomatisasi. CDP berkomunikasi langsung dengan browser berbasis Chromium melalui koneksi WebSocket, yang memberikan performa lebih cepat dan kontrol level rendah.

Namun, pengujian ini hanya berfungsi dengan browser berbasis Chromium dan bukan merupakan standar terbuka. Selain itu, CDP API relatif kompleks. Dalam beberapa kasus, menggunakan CDP tidaklah ergonomis. Misalnya, bekerja dengan iframe di luar proses membutuhkan banyak upaya.

Misalnya, mengklik elemen await coffee.click(); diterjemahkan menjadi serangkaian perintah CDP.

// CDP: Click on a coffee element

// Mouse pressed
{ 
  command: 'Input.dispatchMouseEvent', 
  parameters: {
    type: 'mousePressed', x: 10.34, y: 27.1, clickCount: 1 }
}

// Mouse released
{ 
  command: 'Input.dispatchMouseEvent', 
  parameters: {
    type: 'mouseReleased', x: 10.34, y: 27.1, clickCount: 1 }
}

Apa yang dimaksud dengan kontrol tingkat rendah?

Di masa lalu ketika WebDriver “Klasik” dikembangkan, kontrol tingkat rendah tidak diperlukan. Namun waktu telah berubah, sekarang web jauh lebih mampu melakukannya, dan pengujian saat ini menuntut tindakan yang lebih mendetail.

Karena CDP dirancang untuk mencakup semua kebutuhan proses debug, CDP mendukung kontrol tingkat rendah yang lebih banyak dibandingkan WebDriver “Klasik”. WebDriver ini mampu menangani fitur seperti:

• Mengambil pesan konsol
• Mencegat permintaan jaringan
• Menyimulasikan mode perangkat
• Menyimulasikan geolokasi
• Dan banyak lagi!

Hal ini tidak mungkin dilakukan di WebDriver “Klasik” karena arsitektur yang berbeda—WebDriver “Klasik” berbasis HTTP, sehingga menyulitkan untuk berlangganan dan mendengarkan peristiwa browser. Di sisi lain, CDP berbasis WebSocket, yang mendukung pengiriman pesan dua arah secara default.

Langkah berikutnya: WebDriver BiDi

Berikut adalah ringkasan keunggulan WebDriver “Klasik” dan CDP:

WebDriver BiDi bertujuan untuk menggabungkan aspek terbaik dari WebDriver "Klasik" dan CDP. Ini adalah protokol otomatisasi browser standar baru yang saat ini sedang dalam pengembangan.

Pelajari lebih lanjut project WebDriver BiDi—cara kerjanya, visi, dan proses standardisasinya.