Go-DOM - Penyemak imbas tanpa kepala yang ditulis dalam Go.

Terlalu sedikit untuk dilakukan kadangkala menghasilkan idea gila, dan kali ini; ia adalah untuk menulis penyemak imbas tanpa kepala dalam Go, dengan pelaksanaan DOM penuh dan sokongan JavaScript, dengan membenamkan enjin v8.

Semuanya mula berfungsi dengan menulis aplikasi HTMX, dan keperluan untuk mengujinya yang membuatkan saya tertanya-tanya jika terdapat pelaksanaan Go tulen pelayar tanpa kepala.

Mencari "pelayar tanpa kepala" hanya menghasilkan hasil carian yang bercakap tentang mengautomatikkan penyemak imbas tanpa kepala, iaitu menggunakan penyemak imbas sebenar seperti Chrome of Firefox dalam mod tanpa kepala.

Tetapi tiada apa-apa dalam Go tulen.

Jadi saya mula membina satu.

Mengapa Pelayar Tanpa Kepala dalam Go?

Ia mungkin kelihatan bodoh kerana menulis pelayar tanpa kepala tidak akan berfungsi seperti pelayar sebenar; dan oleh itu tidak akan benar-benar mengesahkan bahawa aplikasi anda berfungsi dengan betul dalam semua penyemak imbas yang anda telah memutuskan untuk menyokong. Ini juga tidak membenarkan anda mendapatkan ciri yang menarik seperti tangkapan skrin aplikasi apabila keadaan berhenti berfungsi.

Jadi kenapa?

Keperluan untuk Kelajuan!

Untuk bekerja dalam gelung TDD yang berkesan, ujian mestilah pantas. Pelaksanaan ujian yang perlahan tidak menggalakkan TDD, dan anda kehilangan faedah kecekapan yang diberikan oleh gelung maklum balas pantas.

Menggunakan automasi penyemak imbas untuk jenis pengesahan ini mempunyai overhed yang teruk, dan ujian sedemikian biasanya ditulis selepas kod ditulis; dan oleh itu, mereka tidak lagi berfungsi sebagai bantuan menulis pelaksanaan yang betul; tetapi dikurangkan kepada beban penyelenggaraan selepas fakta itu; yang hanya sekali-sekala mengesan pepijat sebelum pelanggan yang membayar anda melakukannya.

Matlamatnya adalah untuk mencipta alat yang menyokong proses TDD. Untuk boleh digunakan, ia perlu dijalankan dalam proses.

Ia perlu ditulis dalam Go.

Ujian Kurang Flaky

Mempunyai DOM dalam proses membolehkan menulis pembalut yang lebih baik di atas DOM; yang boleh membantu menyediakan antara muka yang kurang tidak menentu untuk ujian anda, seperti yang dilakukan oleh perpustakaan ujian untuk JavaScript.

Daripada bergantung pada nama kelas CSS, ID elemen atau struktur DOM, anda menulis ujian anda dalam bahasa tertumpu pengguna, seperti ini.

Taip "me@example.com" dalam kotak teks yang mempunyai label, "E-mel"

Atau dalam kod hipotetikal.

testing.GetElement(Query{
  role: "textbox",
  // The accessibility "name" of a textbox _is_ the label
  name: "Email",
}).type("me@example.com")

Ujian ini tidak peduli jika label dilaksanakan sebagai , , atau .

Ini memisahkan pengesahan tingkah laku daripada perubahan UI; tetapi ia ada menguatkuasakan bahawa teks, "E-mel" dikaitkan dengan medan input dengan cara yang boleh diakses. Ini menggabungkan ujian dengan cara pengguna berinteraksi dengan halaman; termasuk mereka yang bergantung pada pembaca skrin untuk menggunakan halaman anda.

Ini mencapai aspek TDD yang paling penting; untuk menulis ujian yang digabungkan dengan tingkah laku konkrit.¹

Walaupun secara teknikal mungkin untuk menulis ujian yang sama untuk penyemak imbas yang tidak diproses; manfaat kod asli adalah penting untuk jenis akses rawak DOM yang kemungkinan besar anda perlukan untuk jenis pembantu ini.

Contoh: JavaScript

Untuk memberikan contoh jenis ujian, saya akan menggunakan contoh serupa daripada JavaScript; juga aplikasi menggunakan HTMX. Ujian ini mengesahkan aliran log masuk umum daripada meminta halaman yang memerlukan pengesahan.

Ia agak panjang, kerana saya telah menggabungkan semua persediaan dan kod pembantu dalam satu fungsi ujian di sini.

testing.GetElement(Query{
  role: "textbox",
  // The accessibility "name" of a textbox _is_ the label
  name: "Email",
}).type("me@example.com")

Secara ringkas ujian melakukan perkara berikut:

1. Tekankan fungsi pengesahan, mensimulasikan respons yang berjaya.
2. Minta halaman yang memerlukan pengesahan
3. Sahkan bahawa penyemak imbas mengubah hala ke halaman log masuk dan URL penyemak imbas dikemas kini. ²
4. Isi borang dengan nilai yang dijangkakan, dan serahkan.
5. Sahkan bahawa penyemak imbas mengubah hala ke halaman asal yang diminta dan ia menunjukkan maklumat untuk pengguna yang terputus.

Secara dalaman ujian memulakan pelayan HTTP. Kerana ini berjalan dalam proses ujian, mengejek dan mengejek logik perniagaan adalah mungkin. Ujian menggunakan jsdom untuk berkomunikasi dengan pelayan HTTP; yang kedua-duanya menghuraikan respons HTML ke dalam DOM, tetapi juga melaksanakan skrip sisi klien dalam kotak pasir yang telah dimulakan, mis. dengan tingkap sebagai skop global.³

Ini membolehkan ujian menulis lapisan HTTP, yang mengesahkan kandungan respons tidak mencukupi. Dalam kes ini; bahawa respons diproses oleh HTMX seperti yang dimaksudkan.

Tetapi selain daripada menunggu beberapa acara HTMX, supaya tidak meneruskan ke awal (atau terlambat) ujian itu sebenarnya tidak mengambil berat tentang HTMX. Malah, jika saya mengalih keluar HTMX daripada borang, menggunakan ubah hala klasik, ujian itu masih lulus.

(Jika saya mengalih keluar teg HTMX sepenuhnya, ujian akan tamat masa menunggu acara HTMX)

Kelajuan? Semak!

Walaupun ujian sebelumnya agak perlahan daripada yang diingini; ia agak pantas, diselesaikan dalam biasanya 150-180ms. Ini terlalu perlahan untuk kebanyakan suite ujian, tetapi ia cukup pantas untuk berfungsi sebagai gelung maklum balas semasa mengusahakan ciri tertentu itu.

Ujian ini bukan sebahagian daripada larian TDD biasa. Ia dijalankan apabila saya mengusahakan ciri itu; atau sejurus sebelum melakukan; memastikan tiada yang pecah. Ini adalah cara biasa untuk menangani "ujian perlahan".

Potensi Peningkatan Kelajuan

Contoh JavaScript menggunakan pelayan HTTP sebenar yang dimulakan pada port rawak. Pelayan berjalan dalam proses pelari ujian, itulah sebabnya kita boleh stub dan mengejek logik perniagaan.

Dalam Go, permintaan HTTP dikendalikan oleh http.Handler, menjadikannya sangat mudah untuk menggunakan logik pengendalian HTTP tanpa benar-benar melancarkan pelayan HTTP.

Dan ini adalah sesuatu yang kod go-dom lakukan sekarang, dan pada masa ini suite ujian berjalan dalam sifar milisaat, dibundarkan kepada milisaat terdekat.⁴

Ujian Mengejek dan Selari?

Keupayaan untuk menjalankan ujian selari hanya bergantung pada keupayaan kod anda untuk dijalankan selari. Oleh kerana ini boleh menggunakan http.Handler, setiap ujian boleh mencipta pengendalinya sendiri; setiap satu dengan kebergantungan berbeza digantikan dengan ujian beregu yang sesuai dengan ujian individu.

Ini membolehkan anda menguji lapisan HTTP secara keseluruhan; menggunakan logik perniagaan stubbed.

Keadaan Semasa Projek?

Hampir tiada dilaksanakan; keadaan semasa adalah hasil kerja kira-kira satu setengah hari. Saya mempunyai tokeniser penstriman asas yang boleh menggunakan strim respons http, yang dihantar kepada penghurai yang mengembalikan Nod.

Kod pada masa ini boleh memproses rentetan (tiada ruang dibenarkan lagi) ke dalam HTMLHtmlElement.

Langkah seterusnya ialah

• Tingkatkan penghurai sedikit sahaja, dan dapatkan beberapa lagi jenis elemen dilaksanakan
• Benamkan enjin v8, menangani ketidakpastian utama; bagaimana objek Go boleh diakses oleh JavaScript dan cara kod Go boleh memeriksa hasil mutasi daripada kod JavaScript.
  • Saya membuat POC yang sangat mudah menggunakan v8go, dan garpu yang kelihatan paling baik dikekalkan. Ia tidak mempunyai ciri yang diperlukan; yang saya telah tambah dalam garpu saya sendiri

Masa Depan Projek?

Ini berkemungkinan besar akan mati :(

Saya tidak sedang mengusahakan projek Go yang mana ini akan bernilai (saya sedang mengusahakan projek node.js). Ia adalah kegembiraan melihat bagaimana jsdom membantu berfungsi sebagai gelung maklum balas untuk aliran pengesahan yang mencetuskan idea bodoh yang menyeronokkan untuk diteruskan. Dan sebagai orang yang mempunyai ADHD, ini adalah corak biasa untuk saya. Saya memulakan sesuatu yang menyeronokkan, berusaha; sehingga sesuatu yang lain mencecah radar dan menarik minat saya.

Melainkan ...

Pembangun lain berpendapat ini adalah idea yang baik dan ingin membantu membinanya.

Saya percaya bahawa alat sedemikian akan sangat membantu untuk mana-mana projek Go yang menggabungkan pemaparan bahagian pelayan dengan skrip pihak pelanggan, termasuk aplikasi berasaskan HTMX.

Projek ini ditemui di sini: https://github.com/stroiman/go-dom

---

1. Matlamat TDD ialah bukan untuk menulis ujian unit. Itu adalah perkara biasa; tetapi tanggapan yang salah sama sekali. ↩

2. Bahagian penting bukanlah bahawa kita dialihkan; tetapi sejarah penyemak imbas mempunyai entri yang betul, memberikan tingkah laku yang wajar bagi fungsi belakang/maju penyemak imbas. Ujian itu sepatutnya benar-benar mengesahkan kandungan sejarah, atau mungkin juga digunakan secara aktif menggunakan API navigasi untuk berulang-alik. Oleh yang demikian; ujian boleh dipertingkatkan dalam hal menerangkan kelakuan yang dijangkakan dari sudut pandangan pengguna. ↩

3. Memulas penyemak imbas tanpa kepala dalam JavaScript mempunyai kelebihan yang tidak adil; kerana DOM simulasi anda sudah pun menjadi objek JavaScript yang sah. Dalam Go, kerja tambahan diperlukan untuk membenarkan skrip sebelah klien memutasi DOM dan membiarkan hasilnya boleh diakses dalam kod ujian. ↩

4. Seperti yang dilaporkan oleh Ginkgo. Ini tidak termasuk overhed pembinaan dan pelancaran, yang mempunyai kelewatan yang ketara tetapi sangat singkat. ↩

Atas ialah kandungan terperinci Go-DOM - Penyemak imbas tanpa kepala yang ditulis dalam Go.. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!