Saya sudah cukup lama berkecimpung dalam pengembangan front-end dan melihat tren selama bertahun-tahun: pengembang muda bekerja dengan paradigma pemrograman baru tanpa memahami konteks historisnya. Tentu saja, wajar jika kita tidak mengetahui sesuatu. Web adalah tempat yang sangat besar dengan beragam keahlian dan spesialisasi, dan kita tidak selalu tahu apa yang tidak kita ketahui. Pembelajaran di bidang ini merupakan sebuah perjalanan yang berkesinambungan, bukan sesuatu yang terjadi sekali dan berakhir. Contoh kasus: Seseorang di tim saya bertanya apakah mungkin untuk mengetahui apakah pengguna keluar dari tab tertentu di UI. Saya menunjukkan acara beforeunload JavaScript. Namun mereka yang telah menangani hal ini sebelumnya mengetahui bahwa hal ini mungkin terjadi karena mereka telah menerima peringatan tentang data yang belum disimpan di situs lain, yang mana beforeunload merupakan kasus penggunaan yang umum. Saya juga menunjukkan halamanSembunyikan dan visibilitasUbah acara kepada kolega saya untuk pengukuran yang baik. Bagaimana saya tahu tentang hal itu? Karena ini muncul di proyek lain, bukan karena saya mempelajarinya saat pertama kali mempelajari JavaScript. Faktanya adalah bahwa kerangka kerja front-end modern berada di pundak raksasa teknologi yang mendahuluinya. Mereka mengabstraksi praktik pengembangan, seringkali demi pengalaman pengembang yang lebih baik yang mengurangi, atau bahkan menghilangkan, kebutuhan untuk mengetahui atau menyentuh apa yang secara tradisional merupakan konsep front-end penting yang mungkin harus diketahui semua orang. Pertimbangkan Model Objek CSS (CSSOM). Anda mungkin berharap bahwa siapa pun yang bekerja di CSS dan JavaScript memiliki banyak pengalaman langsung di CSSOM, namun hal itu tidak selalu terjadi. Ada proyek React untuk situs e-commerce yang saya kerjakan di mana kami perlu memuat stylesheet untuk penyedia pembayaran yang saat ini dipilih. Masalahnya adalah stylesheet dimuat di setiap halaman padahal sebenarnya hanya diperlukan pada halaman tertentu. Pengembang yang ditugaskan untuk mewujudkan hal ini belum pernah memuat stylesheet secara dinamis. Sekali lagi, hal ini dapat dimengerti ketika React mengabstraksikan pendekatan tradisional yang mungkin Anda gunakan. CSSOM mungkin bukan sesuatu yang Anda perlukan dalam pekerjaan sehari-hari. Namun kemungkinan besar Anda perlu berinteraksi dengannya suatu saat nanti, bahkan untuk satu kali saja. Pengalaman inilah yang menginspirasi saya untuk menulis artikel ini. Ada banyak fitur web dan teknologi yang mungkin tidak pernah Anda sentuh secara langsung dalam pekerjaan Anda sehari-hari. Mungkin Anda cukup baru dalam pengembangan web dan tidak menyadarinya karena Anda mendalami abstraksi kerangka kerja tertentu yang tidak mengharuskan Anda untuk mengetahuinya secara mendalam, atau bahkan sama sekali. Saya berbicara secara khusus tentang XML, yang banyak dari kita tahu adalah bahasa kuno yang tidak jauh berbeda dengan HTML. Saya mengemukakan hal ini karena diskusi WHATWG baru-baru ini yang menyarankan bahwa sebagian besar tumpukan XML yang dikenal sebagai pemrograman XSLT harus dihapus dari browser. Ini adalah teknologi lama yang sudah kami miliki selama bertahun-tahun dan dapat digunakan untuk sesuatu yang praktis seperti situasi CSSOM yang dialami tim saya. Pernahkah Anda bekerja dengan XSLT sebelumnya? Mari kita lihat apakah kita terlalu bergantung pada teknologi lama ini dan memanfaatkan fitur-fiturnya di luar konteks XML untuk mengatasi masalah dunia nyata saat ini. XPath: API Pusat Teknologi XML terpenting yang mungkin paling berguna di luar perspektif XML lurus adalah XPath, bahasa kueri yang memungkinkan Anda menemukan node atau atribut apa pun di pohon markup dengan satu elemen root. Saya memiliki ketertarikan pribadi terhadap XSLT, tetapi itu juga bergantung pada XPath, dan ketertarikan pribadi harus dikesampingkan dalam peringkat kepentingan. Argumen untuk menghapus XSLT tidak menyebutkan XPath, jadi menurut saya masih diperbolehkan. Itu bagus karena XPath adalah API sentral dan terpenting dalam rangkaian teknologi ini, terutama ketika mencoba menemukan sesuatu untuk digunakan di luar penggunaan XML normal. Hal ini penting karena, meskipun pemilih CSS dapat digunakan untuk menemukan sebagian besar elemen di halaman Anda, mereka tidak dapat menemukan semuanya. Selain itu, pemilih CSS tidak dapat digunakan untuk menemukan elemen berdasarkan posisinya saat ini di DOM. XPath bisa. Sekarang, beberapa dari Anda yang membaca ini mungkin mengetahui XPath, dan beberapa mungkin tidak. XPath adalah bidang teknologi yang cukup luas, dan saya tidak bisa mengajarkan semua dasar-dasarnya dan juga menunjukkan kepada Anda hal-hal keren yang dapat dilakukan dengannya dalam satu artikel seperti ini. Saya sebenarnya mencoba menulis artikel itu, tetapi rata-rata publikasi Smashing Magazine tidak melebihi 5.000 kata. Saya sudah berada di lebih dari2.000 kata sementara hanya setengah dari dasar-dasarnya. Jadi, saya akan mulai melakukan hal-hal keren dengan XPath dan memberi Anda beberapa tautan yang dapat Anda gunakan untuk dasar-dasarnya jika menurut Anda hal ini menarik. Menggabungkan XPath & CSS XPath dapat melakukan banyak hal yang tidak dapat dilakukan oleh penyeleksi CSS saat menanyakan elemen. Namun penyeleksi CSS juga dapat melakukan beberapa hal yang tidak dapat dilakukan XPath, yaitu mengkueri elemen berdasarkan nama kelas.
CSS XPath .Kelasku /*[berisi(@kelas, "Kelas Saya")]
Dalam contoh ini, elemen kueri CSS yang berisi nama kelas .myClass. Sementara itu, contoh XPath menanyakan elemen yang berisi atribut kelas dengan string “myClass”. Dengan kata lain, ia memilih elemen dengan myClass di atribut apa pun, termasuk elemen dengan nama kelas .myClass — serta elemen dengan “myClass” di stringnya, seperti .myClass2. XPath lebih luas dalam hal itu. Jadi tidak. Saya tidak menyarankan kita membuang CSS dan mulai memilih semua elemen melalui XPath. Bukan itu intinya. Intinya adalah bahwa XPath dapat melakukan hal-hal yang tidak dapat dilakukan oleh CSS dan masih bisa sangat berguna, meskipun ini adalah teknologi yang lebih tua di tumpukan browser dan mungkin tidak terlihat jelas pada pandangan pertama. Mari kita gunakan kedua teknologi ini bersama-sama bukan hanya karena kita bisa, namun karena kita akan mempelajari sesuatu tentang XPath dalam prosesnya, menjadikannya alat lain dalam tumpukan Anda — alat yang mungkin belum Anda ketahui telah ada sejak lama! Masalahnya adalah metode document.evaluate JavaScript dan berbagai metode pemilih kueri yang kami gunakan dengan API CSS untuk JavaScript tidak kompatibel. Saya telah membuat API kueri yang kompatibel untuk memulai, meskipun harus diakui, saya belum terlalu memikirkannya karena ini berbeda dengan apa yang kami lakukan di sini. Berikut ini contoh kerja yang cukup sederhana dari konstruktor kueri yang dapat digunakan kembali: Lihat Pena queryXPath [bercabang] oleh Bryan Rasmussen. Saya telah menambahkan dua metode pada objek dokumen: queryCSSSelectors (yang pada dasarnya adalah querySelectorAll) dan queryXPaths. Keduanya mengembalikan objek queryResults:
{ Tipe Kueri: node | tali | nomor | boolean, hasil: any[] // elemen html, elemen xml, string, angka, boolean, queryCSSSelectors: (query: string, ubah: boolean) => queryResults, queryXpaths: (query: string, ubah: boolean) => queryResults }
Fungsi queryCSSSelectors dan queryXpaths menjalankan kueri yang Anda berikan pada elemen dalam larik hasil, tentu saja selama larik hasil bertipe node. Jika tidak, ia akan mengembalikan queryResult dengan array kosong dan tipe node. Jika properti amend disetel ke true, fungsi akan mengubah hasil kuerinya sendiri. Dalam situasi apa pun ini tidak boleh digunakan dalam lingkungan produksi. Saya melakukannya dengan cara ini murni untuk menunjukkan berbagai efek penggunaan dua API kueri secara bersamaan. Contoh Pertanyaan Saya ingin menunjukkan beberapa contoh kueri XPath berbeda yang menunjukkan beberapa hal hebat yang bisa mereka lakukan dan bagaimana mereka bisa digunakan sebagai pengganti pendekatan lain. Contoh pertama adalah //li/teks(). Ini menanyakan semua elemen li dan mengembalikan node teksnya. Jadi, jika kita menanyakan HTML berikut:
- satu
- dua
- tiga
…inilah yang dikembalikan:
{"queryType":"xpathEvaluate","results":["satu","dua","tiga"],"resultType":"string"}
Dengan kata lain, kita mendapatkan array berikut: ["one","two","three"]. Biasanya, Anda akan menanyakan elemen li untuk mendapatkannya, mengubah hasil kueri tersebut menjadi array, memetakan array, dan mengembalikan node teks dari setiap elemen. Namun kita dapat melakukannya secara lebih ringkas dengan XPath: dokumen.queryXPaths("//li/text()").hasil.
Perhatikan bahwa cara untuk mendapatkan node teks adalah dengan menggunakan text(), yang terlihat seperti tanda tangan fungsi — dan memang demikian. Ini mengembalikan simpul teks suatu elemen. Dalam contoh kita, ada tiga elemen li dalam markup, masing-masing berisi teks ("satu", "dua", dan "tiga").
Mari kita lihat satu lagi contoh query text(). Asumsikan ini adalah markup kita:
Mari tulis kueri yang mengembalikan nilai atribut href: document.queryXPaths("//a[teks() = 'Masuk']/@href").hasil.
Ini adalah kueri XPath pada dokumen saat ini, sama seperti contoh terakhir, tetapi kali ini kami mengembalikan atribut href dari tautan (elemen) yang berisi teks “Masuk”. Yang sebenarnya kembalihasilnya adalah ["/login.html"]. Ikhtisar Fungsi XPath Ada sejumlah fungsi XPath, dan Anda mungkin belum mengenalnya. Menurut saya, ada beberapa hal yang perlu diketahui, antara lain sebagai berikut:
dimulai denganJika sebuah teks dimulai dengan contoh teks tertentu lainnya, dimulai dengan(@href, 'http:') mengembalikan nilai true jika atribut href dimulai dengan http:. berisiJika suatu teks berisi contoh teks tertentu lainnya, berisi(teks(), "Smashing Magazine") mengembalikan nilai true jika node teks berisi kata-kata "Smashing Magazine" di dalamnya di mana saja. countMengembalikan jumlah kecocokan yang ada pada kueri. Misalnya, count(//*[starts-with(@href, 'http:']) mengembalikan hitungan berapa banyak tautan dalam simpul konteks yang memiliki elemen dengan atribut href yang berisi teks yang diawali dengan http:. substringBekerja seperti substring JavaScript, kecuali Anda meneruskan string sebagai argumen. Misalnya, substring("teks saya", 2, 4) mengembalikan "y t". substring-before Mengembalikan bagian string sebelum string lainnya. Misalnya, substing-before("my text", " ") mengembalikan "my". Demikian pula, substring-before("hi","bye") mengembalikan string kosong. substring-afterMengembalikan bagian dari string setelah string lainnya. Misalnya, substing-after("my text", " ") mengembalikan "text". Demikian pula, substring-after("hi","bye") mengembalikan string kosong. normalize-spaceMengembalikan string argumen dengan spasi yang dinormalisasi dengan menghapus spasi di depan dan di belakang dan mengganti urutan karakter spasi dengan satu spasi. notMengembalikan boolean benar jika argumennya salah, jika tidak maka salah. trueMengembalikan boolean benar. false Mengembalikan boolean salah. concat Hal yang sama seperti concat JavaScript, kecuali Anda tidak menjalankannya sebagai metode pada string. Sebagai gantinya, Anda memasukkan semua string yang ingin Anda gabungkan. string-lengthIni tidak sama dengan string-length JavaScript, melainkan mengembalikan panjang string yang diberikan sebagai argumen. TranslateThis mengambil string dan mengubah argumen kedua menjadi argumen ketiga. Misalnya, Translate("abcdef", "abc", "XYZ") menghasilkan XYZdef.
Selain fungsi-fungsi XPath khusus ini, ada sejumlah fungsi lain yang bekerja sama dengan fungsi-fungsi JavaScript lainnya — atau fungsi-fungsi tersebut pada dasarnya dalam bahasa pemrograman apa pun — yang mungkin juga berguna bagi Anda, seperti floor, langit-langit, putaran, jumlah, dan sebagainya. Demo berikut mengilustrasikan masing-masing fungsi ini: Lihat fungsi Numerik Pen XPath [bercabang] oleh Bryan Rasmussen. Perhatikan bahwa, seperti kebanyakan fungsi manipulasi string, banyak fungsi numerik yang mengambil satu masukan. Hal ini tentu saja karena mereka seharusnya digunakan untuk query, seperti pada contoh XPath terakhir: //li[lantai(teks()) > 250]/@val
Jika Anda menggunakannya, seperti kebanyakan contoh, Anda akan menjalankannya pada node pertama yang cocok dengan jalurnya. Ada juga beberapa fungsi konversi tipe yang mungkin harus Anda hindari karena JavaScript sudah memiliki masalah konversi tipenya sendiri. Namun ada kalanya Anda ingin mengonversi string menjadi angka untuk membandingkannya dengan angka lain. Fungsi yang mengatur tipe sesuatu adalah boolean, number, string, dan node. Ini adalah tipe data XPath yang penting. Dan seperti yang Anda bayangkan, sebagian besar fungsi ini dapat digunakan pada tipe data yang bukan node DOM. Misalnya, substring-after mengambil string seperti yang telah kita bahas, tapi bisa juga string dari atribut href. Itu juga bisa berupa string:
const testSubstringAfter = document.queryXPaths("substring-after('hello world',' ')");
Jelasnya, contoh ini akan mengembalikan array hasil kepada kita sebagai ["dunia"]. Untuk menunjukkan tindakan ini, saya telah membuat halaman demo menggunakan fungsi terhadap hal-hal yang bukan node DOM: Lihat Pena queryXPath [bercabang] oleh Bryan Rasmussen. Anda harus memperhatikan aspek mengejutkan dari fungsi terjemahan, yaitu jika Anda memiliki karakter dalam argumen kedua (yaitu, daftar karakter yang ingin Anda terjemahkan) dan tidak ada karakter yang cocok untuk diterjemahkan, karakter tersebut akan dihapus dari output. Jadi, ini:
menerjemahkan('Halo, Nama Saya Inigo Montoya, kamu membunuh ayahku, bersiaplah untuk mati','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*')
…menghasilkan string, termasuk spasi: ["* * ** "]
Ini berarti huruf “a” diterjemahkan menjadi tanda bintang (*), tetapi setiap karakter lain yang tidak memiliki terjemahan mengingat string target akan dihapus seluruhnya. Hanya spasi putih yang tersisaantara karakter “a” yang diterjemahkan. Kemudian lagi, pertanyaan ini:
menerjemahkan('Halo, Nama Saya Inigo Montoya, kamu membunuh ayahku, bersiaplah untuk mati','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','***************************************************')")
…tidak ada masalah dan menghasilkan hasil seperti ini:
"***** ** **** ** ***** ******* *** ****** ** ****** ******* ** ***"
Anda mungkin terkejut bahwa tidak ada cara mudah dalam JavaScript untuk melakukan persis seperti fungsi terjemahan XPath, meskipun untuk banyak kasus penggunaan, replaceAll dengan ekspresi reguler dapat mengatasinya. Anda dapat menggunakan pendekatan yang sama yang telah saya tunjukkan, tetapi itu kurang optimal jika yang Anda inginkan hanyalah menerjemahkan stringnya. Demo berikut menggabungkan fungsi terjemahan XPath untuk menyediakan versi JavaScript: Lihat fungsi terjemahan Pena [bercabang] oleh Bryan Rasmussen. Di mana Anda bisa menggunakan sesuatu seperti ini? Pertimbangkan enkripsi Caesar Cipher dengan offset tiga tempat (misalnya, enkripsi terbaik dari tahun 48 SM):
Translate("Caesar berencana menyeberangi Rubicon!", "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz", "XYZABCDEFGHIJKLMNOPQRSTUVWxyzabcdefghijklmnopqrstuvw")
Teks masukan “Caesar berencana menyeberangi Rubicon!” menghasilkan “Zxbpxo fp mixkkfkd ql zolpp qeb Oryfzlk!” Untuk memberikan contoh singkat lainnya tentang berbagai kemungkinan, saya membuat fungsi logam yang mengambil input string dan menggunakan fungsi terjemahan untuk mengembalikan teks, termasuk semua karakter yang menggunakan umlaut. Lihat fungsi Pen metal [bercabang] oleh Bryan Rasmussen.
konstanta logam = (str) => { return Translate(str, "AOUaou","ÄÖÜäöü"); }
Dan, jika diberi teks “Motley Crue rule, rock on dudes!”, akan menghasilkan “Mötley Crüe rüles, röck ön düdes!” Tentu saja, seseorang mungkin memiliki berbagai macam parodi yang menggunakan fungsi ini. Jika itu Anda, artikel TVTropes ini akan memberi Anda banyak inspirasi. Menggunakan CSS Dengan XPath Ingat alasan utama kami menggunakan penyeleksi CSS bersama dengan XPath: CSS cukup memahami apa itu kelas, sedangkan hal terbaik yang dapat Anda lakukan dengan XPath adalah perbandingan string dari atribut kelas. Itu akan berhasil dalam banyak kasus. Namun jika Anda pernah mengalami situasi di mana, katakanlah, seseorang membuat kelas bernama .primaryLinks dan .primaryLinks2 dan Anda menggunakan XPath untuk mendapatkan kelas .primaryLinks, kemungkinan besar Anda akan mengalami masalah. Selama tidak ada yang konyol seperti itu, Anda mungkin akan menggunakan XPath. Namun dengan sedih saya laporkan bahwa saya pernah bekerja di tempat di mana orang-orang melakukan hal-hal konyol seperti itu. Berikut demo lainnya menggunakan CSS dan XPath secara bersamaan. Ini menunjukkan apa yang terjadi ketika kita menggunakan kode untuk menjalankan XPath pada node konteks yang bukan node dokumen. Lihat Pen css dan xpath bersama-sama [bercabang] oleh Bryan Rasmussen. Kueri CSS adalah .relatedarticles a, yang mengambil dua elemen a dalam div yang diberi kelas .relatedarticles. Setelah itu ada tiga kueri "buruk", yaitu kueri yang tidak melakukan apa yang kita inginkan saat dijalankan dengan elemen ini sebagai simpul konteks. Saya dapat menjelaskan mengapa mereka berperilaku berbeda dari yang Anda duga. Tiga pertanyaan buruk yang dimaksud adalah:
//text(): Mengembalikan semua teks dalam dokumen. //a/text(): Mengembalikan semua teks di dalam tautan dalam dokumen. ./a/text(): Tidak memberikan hasil apa pun.
Alasan untuk hasil ini adalah meskipun konteks Anda adalah elemen yang dikembalikan dari kueri CSS, // bertentangan dengan keseluruhan dokumen. Inilah kekuatan XPath; CSS tidak bisa berpindah dari sebuah simpul ke nenek moyang dan kemudian ke saudara dari nenek moyang itu, dan turun ke keturunan dari saudara itu. Tapi XPath bisa. Sementara itu, ./ menanyakan turunan dari simpul saat ini, dengan titik (.) mewakili simpul saat ini, dan garis miring (/) mewakili pergi ke beberapa simpul turunan — apakah itu atribut, elemen, atau teks ditentukan oleh bagian jalur berikutnya. Namun tidak ada elemen turunan yang dipilih oleh kueri CSS, sehingga kueri tersebut juga tidak mengembalikan apa pun. Ada tiga pertanyaan bagus dalam demo terakhir itu:
.//teks(), ./teks(), normalisasi-spasi(./teks()).
Kueri ruang normalisasi menunjukkan penggunaan fungsi XPath, namun juga memperbaiki masalah yang disertakan dalam kueri lainnya. Struktur HTMLnya seperti ini:
Mengotomatiskan Pengujian Fitur Anda Dengan Selenium WebDriver
Kueri mengembalikan umpan baris di awal dan akhir simpul teks,dan normalisasi-ruang menghapus ini. Menggunakan fungsi XPath apa pun yang mengembalikan sesuatu selain boolean dengan input XPath berlaku untuk fungsi lainnya. Demo berikut menunjukkan sejumlah contoh: Lihat contoh fungsi Pen xpath [bercabang] oleh Bryan Rasmussen. Contoh pertama menunjukkan masalah yang harus Anda waspadai. Secara khusus, kode berikut:
document.queryXPaths("substring-after(//a/@href,'https://')");
…mengembalikan satu string:
"www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/"
Masuk akal, bukan? Fungsi-fungsi ini tidak mengembalikan array melainkan string tunggal atau angka tunggal. Menjalankan fungsi di mana saja dengan banyak hasil hanya akan mengembalikan hasil pertama. Hasil kedua menunjukkan apa yang sebenarnya kita inginkan:
document.queryCSSSelectors("a").queryXPaths("substring-after(./@href,'https://')");
Yang mengembalikan array dua string:
["www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/","www.smashingmagazine.com/2022/11/automated-test-results-improve-accessibility/"]
Fungsi XPath dapat disarangkan seperti fungsi di JavaScript. Jadi, jika kita mengetahui struktur URL Smashing Magazine, kita dapat melakukan hal berikut (disarankan menggunakan literal template): `menerjemahkan( substring( substring-setelah(./@href, 'www.smashingmagazine.com/') ,9), '/','')`
Ini menjadi agak terlalu rumit sehingga memerlukan komentar yang menjelaskan fungsinya: ambil semua URL dari atribut href setelah www.smashingmagazine.com/, hapus sembilan karakter pertama, lalu terjemahkan karakter garis miring (/) menjadi nol untuk menghilangkan akhiran garis miring. Array yang dihasilkan:
["pengujian-fitur-selenium-webdriver","hasil-pengujian-otomatis-meningkatkan-aksesibilitas"]
Lebih Banyak Kasus Penggunaan XPath XPath benar-benar bisa bersinar dalam pengujian. Alasannya tidak sulit untuk dilihat, karena XPath dapat digunakan untuk mendapatkan setiap elemen di DOM, dari posisi mana pun di DOM, sedangkan CSS tidak bisa. Anda tidak dapat mengandalkan kelas CSS yang tetap konsisten di banyak sistem pembangunan modern, namun dengan XPath, kami dapat membuat pencocokan yang lebih kuat mengenai konten teks suatu elemen, terlepas dari perubahan struktur DOM. Ada penelitian tentang teknik yang memungkinkan Anda membuat tes XPath yang tangguh. Tidak ada yang lebih buruk daripada pengujian yang gagal dan gagal hanya karena pemilih CSS tidak lagi berfungsi karena ada sesuatu yang diganti namanya atau dihapus. XPath juga sangat hebat dalam ekstraksi banyak pencari lokasi. Ada lebih dari satu cara untuk menggunakan kueri XPath untuk mencocokkan suatu elemen. Hal yang sama berlaku dengan CSS. Namun kueri XPath dapat menelusuri hal-hal dengan cara yang lebih bertarget yang membatasi apa yang dikembalikan, memungkinkan Anda menemukan kecocokan tertentu di mana mungkin ada beberapa kemungkinan kecocokan. Misalnya, kita dapat menggunakan XPath untuk mengembalikan elemen h2 tertentu yang terdapat di dalam div yang langsung mengikuti div saudaranya yang, pada gilirannya, berisi elemen gambar anak dengan atribut data-testID="leader" di dalamnya:
jangan lihat judul ini
Juga tidak mendapatkan judul ini
Header untuk gambar pemimpin
Ini pertanyaannya: dokumen.queryXPaths(` //div[ saudara-berikut::div[1] /img[@data-testID='pemimpin'] ] /h2/ teks() `);
Mari kita lihat demonya untuk melihat bagaimana semuanya menyatu: Lihat Kueri H2 Kompleks Pena [bercabang] oleh Bryan Rasmussen. Jadi ya. Ada banyak kemungkinan jalur ke elemen apa pun dalam pengujian menggunakan XPath. Penghentian XSLT 1.0 Saya sebutkan sebelumnya bahwa tim Chrome berencana menghapus dukungan XSLT 1.0 dari browser. Hal ini penting karena XSLT 1.0 menggunakan pemrograman yang berfokus pada XML untuk transformasi dokumen yang, pada gilirannya, bergantung pada XPath 1.0, yang ditemukan di sebagian besar browser. Jika hal ini terjadi, kita akan kehilangan komponen kunci XPath. Namun mengingat fakta bahwa XPath sangat bagus untuk tes menulis, saya merasa kecil kemungkinannya bahwa XPath secara keseluruhan akan hilang dalam waktu dekat. Meskipun demikian, saya memperhatikan bahwa orang-orang akan tertarik pada suatu fitur ketika fitur tersebut dihapus. Dan hal ini memang benar jika XSLT 1.0 tidak digunakan lagi. Ada seluruh diskusi yang terjadi di Hacker News yang berisi argumen yang menentang penghentian tersebut. Postingan itu sendiri adalah contoh bagus dalam membuat kerangka blogging dengan XSLT. Andadapat membaca diskusinya sendiri, tetapi ini membahas bagaimana JavaScript dapat digunakan sebagai pengganti XLST untuk menangani kasus-kasus semacam itu. Saya juga melihat saran agar browser menggunakan SaxonJS, yang merupakan port ke mesin JavaScript Saxon XSLT, XQUERY, dan XPath. Itu ide yang menarik, terutama karena Saxon-JS mengimplementasikan versi terbaru dari spesifikasi ini, sedangkan tidak ada browser yang mengimplementasikan versi XPath atau XSLT apa pun di luar 1.0, dan tidak ada yang mengimplementasikan XQuery. Saya menghubungi Norm Tovey-Walsh di Saxonica, perusahaan di balik SaxonJS dan versi lain dari mesin Saxon. Dia berkata: “Jika ada vendor browser yang tertarik menggunakan SaxonJS sebagai titik awal untuk mengintegrasikan teknologi XML modern ke dalam browser, kami akan dengan senang hati mendiskusikannya dengan mereka.”— Norm Tovey-Walsh
Namun juga ditambahkan: "Saya akan sangat terkejut jika ada yang berpikir bahwa menggunakan SaxonJS dalam bentuknya saat ini dan memasukkannya ke dalam versi browser tanpa perubahan akan menjadi pendekatan yang ideal. Vendor browser, berdasarkan fakta bahwa mereka membuat browser, dapat melakukan pendekatan integrasi pada tingkat yang jauh lebih dalam daripada yang bisa kita lakukan 'dari luar'."— Norm Tovey-Walsh
Perlu dicatat bahwa komentar Tovey-Walsh muncul sekitar seminggu sebelum pengumuman penghentian XSLT. Kesimpulan Saya bisa melanjutkan dan melanjutkan. Namun saya harap ini menunjukkan kekuatan XPath dan memberi Anda banyak contoh yang menunjukkan cara menggunakannya untuk mencapai hal-hal hebat. Ini adalah contoh sempurna dari teknologi lama di tumpukan browser yang masih memiliki banyak kegunaan hingga saat ini, bahkan jika Anda belum pernah mengetahui keberadaannya atau tidak pernah mempertimbangkan untuk menggunakannya. Bacaan Lebih Lanjut
“Meningkatkan Ketahanan Tes Web Otomatis dengan Bahasa Alami” (Perpustakaan Digital ACM) oleh Maroun Ayli, Youssef Bakouny, Nader Jalloul, dan Rima KilanyArtikel ini memberikan banyak contoh XPath untuk menulis tes ketahanan. XPath (MDN) Ini adalah tempat yang bagus untuk memulai jika Anda menginginkan penjelasan teknis yang merinci cara kerja XPath. Tutorial XPath (ZVON)Menurut saya tutorial ini paling membantu dalam pembelajaran saya sendiri, berkat banyak contoh dan penjelasan yang jelas. XPatherAlat interaktif ini memungkinkan Anda bekerja secara langsung dengan kode.
