Apa ini?
Transisi dari Manifes V2 ke Manifes V3 hadir dengan perubahan mendasar. Di Manifes V2, ekstensi berada di halaman latar belakang. Halaman latar belakang mengelola komunikasi antara ekstensi dan halaman web. Manifes V3 menggunakan pekerja layanan sebagai gantinya.
Dalam postingan ini, kami akan mendalami masalah saat menguji pekerja layanan ekstensi. Secara khusus, kita melihat cara untuk memastikan bahwa produk kita berfungsi dengan benar jika pekerja layanan ditangguhkan.
Siapa kita?
eyeo adalah perusahaan yang didedikasikan untuk memberdayakan pertukaran nilai online yang seimbang dan berkelanjutan bagi pengguna, browser, pengiklan, dan penayang. Kami memiliki lebih dari 300 juta pengguna global yang memfilter iklan yang mengizinkan tampilan Iklan yang Dapat Diterima, standar iklan yang berasal dari independen untuk menentukan apakah sebuah iklan dapat diterima dan tidak mengganggu.
Tim Ekstensi Engine kami menyediakan teknologi pemfilteran iklan yang mendukung beberapa ekstensi browser pemblokir iklan terpopuler di pasar, seperti AdBlock dan Adblock Plus dengan lebih dari 110 juta pengguna di seluruh dunia. Selain itu, kami menawarkan teknologi ini sebagai library open source, sehingga tersedia untuk ekstensi browser pemfilteran iklan lainnya.
Apa yang dimaksud dengan pekerja layanan?
Pekerja layanan ekstensi adalah pengendali peristiwa pusat ekstensi browser. Keduanya berjalan secara independen di latar belakang. Umumnya hal ini tidak menjadi masalah. Kita bisa melakukan sebagian besar hal yang perlu kita lakukan di halaman latar belakang dalam pekerja layanan baru. Namun, ada beberapa perubahan jika dibandingkan dengan halaman latar belakang:
- Pekerja layanan dihentikan saat tidak digunakan. Hal ini mengharuskan kita untuk mempertahankan status aplikasi, bukan mengandalkan variabel global. Artinya, setiap titik masuk ke sistem harus disiapkan untuk dipanggil sebelum sistem diinisialisasi.
- Pemroses peristiwa harus dilampirkan sebelum menunggu callback asinkron. Pekerja layanan yang ditangguhkan masih dapat menerima peristiwa langganannya. Jika pemroses untuk peristiwa tidak terdaftar pada putaran pertama loop peristiwa, ia tidak akan menerima peristiwa jika peristiwa tersebut membangunkan pekerja layanan.
- Penghentian tidak ada aktivitas dapat mengganggu timer sebelum selesai.
Kapan pekerja layanan ditangguhkan?
Untuk Chrome 119, yang kami alami adalah pekerja layanan ditangguhkan:
- Setelah tidak menerima peristiwa atau memanggil API ekstensi selama 30 detik.
- Jangan pernah jika alat developer terbuka atau Anda menggunakan library pengujian berbasis ChromeDriver (lihat permintaan fitur).
- Jika Anda mengklik Stop di chrome://serviceworker-internals.
Untuk mengetahui informasi terbaru, lihat Siklus Proses Service Worker.
Mengapa pengujian ini menjadi masalah?
Idealnya, akan sangat berguna jika memiliki panduan resmi tentang "cara menguji pekerja layanan dengan cara yang efisien" atau contoh pengujian yang berfungsi. Selama petualangan kami dalam menguji pekerja layanan, kami menghadapi beberapa tantangan:
- Kita memiliki status dalam ekstensi pengujian. Saat pekerja layanan berhenti, kita akan kehilangan status dan peristiwa terdaftarnya. Bagaimana cara mempertahankan data dalam alur pengujian?
- Jika pekerja layanan dapat ditangguhkan kapan saja, kita perlu menguji apakah semua fitur berfungsi jika terhenti.
- Meskipun kami memperkenalkan mekanisme dalam pengujian yang menangguhkan pekerja layanan secara acak, tidak ada API di browser untuk menangguhkannya dengan mudah. Kami telah meminta tim W3C untuk menambahkan fitur ini, tetapi itu adalah percakapan yang sedang berlangsung.
Menguji Penangguhan Service Worker
Kami telah mencoba beberapa pendekatan untuk memicu penangguhan pekerja layanan selama pengujian:
| Pendekatan | Masalah terkait pendekatan |
| Menunggu selama durasi tertentu (misalnya 30 detik) | Hal ini membuat pengujian menjadi lambat dan tidak dapat diandalkan, terutama saat menjalankan beberapa pengujian. Ini tidak berfungsi ketika menggunakan WebDriver, karena WebDriver menggunakan Chrome DevTools API, dan pekerja layanan tidak ditangguhkan saat DevTools terbuka. Meskipun bisa melewatinya, kita masih harus memeriksa apakah pekerja layanan ditangguhkan dan tidak ada cara untuk melakukannya. |
| Menjalankan loop tanpa batas di pekerja layanan | Menurut spesifikasi, hal ini dapat menyebabkan penghentian bergantung pada cara browser menerapkan fungsi ini. Dalam kasus ini, Chrome tidak menghentikan pekerja layanan sehingga kami tidak dapat menguji skenario saat pekerja layanan ditangguhkan. |
| Memiliki pesan di pekerja layanan untuk memeriksa apakah layanan telah ditangguhkan | Mengirim pesan akan membangunkan pekerja layanan. Ini dapat digunakan untuk memeriksa apakah pekerja layanan tidur, tetapi merusak hasil untuk pengujian yang perlu melakukan pemeriksaan dengan segera setelah menangguhkan pekerja layanan. |
| Menghentikan proses pekerja layanan menggunakan chrome.processes.terminate() | Pekerja layanan untuk ekstensi berbagi proses dengan bagian lain dari ekstensi, sehingga menghentikan proses ini menggunakan chrome.process.terminate() atau GUI pengelola proses Chrome tidak hanya mematikan pekerja layanan, tetapi juga halaman ekstensi apa pun. |
Kita berakhir dengan pengujian yang memeriksa bagaimana kode kita merespons pekerja layanan yang ditangguhkan dengan membuat Selenium WebDriver membuka chrome://serviceworker-internals/ dan mengklik tombol "stop" untuk pekerja layanan.
Ini adalah opsi terbaik sejauh ini, tetapi tidak ideal karena pengujian Mocha (yang berjalan di halaman ekstensi) tidak dapat melakukannya sendiri, sehingga harus berkomunikasi kembali ke program node WebDriver. Artinya, pengujian ini tidak dapat dijalankan hanya dengan menggunakan ekstensi; pengujian harus dipicu menggunakan Selenium WebDriver.
Berikut adalah diagram mengenai cara kita berkomunikasi dengan API browser melalui alur yang berbeda dan pengaruh penambahan mekanisme "penangguhan service worker" memengaruhinya.
Dalam alur baru yang menangguhkan pekerja layanan (biru), kami telah menambahkan Selenium WebDriver untuk "mengklik" menangguhkan melalui UI, yang memicu tindakan di API browser.
Perlu diperhatikan bahwa ada bug Chrome saat melakukan ini dengan Selenium WebDriver menyebabkan pekerja layanan tidak dapat memulai lagi. Hal ini telah diperbaiki di Chrome 116 dan untungnya, ada juga solusi: menyetel Chrome untuk membuka DevTools secara otomatis di setiap tab akan membuat pekerja layanan dimulai dengan benar.
Ini adalah pendekatan yang kita gunakan saat melakukan pengujian meskipun itu tidak ideal karena mengklik tombol mungkin bukan API yang stabil dan membuka DevTools (untuk browser lama) tampaknya menghabiskan biaya performa.
Bagaimana kita membahas seluruh fungsinya? Pengujian Bulu Halus
Setelah kami memiliki mekanisme untuk menguji penangguhan, kami harus memutuskan cara menghubungkannya ke rangkaian pengujian otomatisasi. Kami menjalankan pengujian standar di lingkungan tempat sebelum setiap interaksi dengan halaman latar belakang, pekerja layanan ditangguhkan oleh WebDriver dengan mengklik Stop di halaman chrome://serviceworker-internals/.
Kami menjalankan sebagian besar dan tidak semua pengujian karena mekanisme penangguhan tidak sepenuhnya stabil, dan terkadang menyebabkan kegagalan. Selain itu, menjalankan semua rangkaian pengujian dalam mode fuzz membutuhkan banyak waktu. Jadi, alih-alih membahas semua kasus yang "serupa", kami memilih jalur yang paling penting untuk pengujian dalam mode fuzz. Perlu disebutkan bahwa menjalankan pengujian fungsional dalam mode "fuzz" berarti kita harus meningkatkan waktu tunggu pengujian karena menangguhkan dan memulai ulang pekerja layanan memerlukan waktu tambahan.
Pengujian ini bermanfaat sebagai first pass yang bersifat kasar, yang menyoroti banyak tempat di mana kode gagal, namun mungkin tidak serta merta mengungkap semua cara tersembunyi yang mungkin disebabkan oleh penangguhan pekerja layanan.
Secara internal, kami menyebut pengujian semacam ini sebagai "Pengujian Fuzz". Biasanya, pengujian fuzz adalah saat Anda menampilkan input yang tidak valid ke program dan memastikan program tersebut merespons secara wajar, atau setidaknya tidak error. Dalam kasus ini, "input tidak valid" adalah pekerja layanan yang ditangguhkan kapan saja, dan "perilaku wajar" yang diharapkan adalah fungsi pemfilteran iklan harus tetap berfungsi seperti sebelumnya. Ini bukan input yang benar-benar tidak valid karena ini adalah perilaku yang diharapkan dalam Manifes V3, tetapi ini akan menjadi tidak valid di Manifes V2 sehingga terasa seperti terminologi yang masuk akal.
Ringkasan
Service worker adalah salah satu perubahan terbesar di Manifes V3 (selain aturan deklaratifNetRequest). Migrasi ke Manifes V3 mungkin memerlukan banyak perubahan kode di ekstensi browser dan pendekatan baru untuk pengujian. Hal ini juga mengharuskan developer ekstensi dengan status persisten menyiapkan ekstensinya untuk menangani penangguhan pekerja layanan yang tidak terduga secara halus.
Sayangnya, tidak ada API untuk menangani penangguhan dengan cara mudah yang sesuai dengan kasus penggunaan kita. Karena kami ingin menguji keandalan codebase ekstensi terhadap mekanisme penangguhan pada tahap awal, kami harus mengatasinya. Developer ekstensi lain yang menghadapi tantangan serupa dapat menggunakan solusi ini. Solusi ini, meskipun memakan waktu dalam tahap pengembangan dan pemeliharaan, akan sangat bermanfaat, sehingga kami dapat memastikan bahwa ekstensi kami dapat berhasil beroperasi di lingkungan tempat pekerja layanan ditangguhkan secara rutin.
Meskipun sudah ada dukungan dasar untuk menguji penangguhan pekerja layanan, dukungan platform yang lebih baik untuk menguji pekerja layanan dari dalam ekstensi adalah sesuatu yang benar-benar kami inginkan pada masa mendatang, karena dapat mengurangi waktu eksekusi pengujian dan upaya pemeliharaan secara signifikan.