Jeg har vært i front-end-utvikling lenge nok til å se en trend gjennom årene: yngre utviklere jobber med et nytt paradigme for programmering uten å forstå den historiske konteksten til det. Det er selvfølgelig helt forståelig å ikke vite noe. Internett er et veldig stort sted med et mangfoldig sett av ferdigheter og spesialiteter, og vi vet ikke alltid hva vi ikke vet. Læring i dette feltet er en pågående reise snarere enn noe som skjer én gang og slutter. Eksempel: Noen i teamet mitt spurte om det var mulig å se om brukere navigerer bort fra en bestemt fane i brukergrensesnittet. Jeg påpekte JavaScripts beforeunload-hendelse. Men de som har taklet dette før, vet at dette er mulig fordi de har blitt truffet med varsler om ulagrede data på andre nettsteder, som før avlasting er en typisk brukstilfelle. Jeg påpekte også siden Skjul og synlighetChange-hendelser til min kollega for godt mål. Hvordan visste jeg om det? Fordi det kom opp i et annet prosjekt, ikke fordi jeg studerte det da jeg først lærte JavaScript. Faktum er at moderne front-end-rammeverk står på skuldrene til teknologigigantene som gikk foran dem. De abstraherer utviklingspraksis, ofte for en bedre utvikleropplevelse som reduserer, eller til og med eliminerer, behovet for å vite eller ta på det som tradisjonelt har vært essensielle front-end-konsepter som alle sannsynligvis burde kjenne til. Vurder CSS Object Model (CSSOM). Du kan forvente at alle som jobber med CSS og JavaScript har en haug med praktisk CSSOM-erfaring, men det kommer ikke alltid til å være tilfelle. Det var et React-prosjekt for en e-handelsside jeg jobbet med der vi trengte å laste et stilark for den valgte betalingsleverandøren. Problemet var at stilarket ble lastet inn på hver side når det egentlig bare var nødvendig på en bestemt side. Utvikleren som fikk i oppgave å få dette til, hadde aldri lastet et stilark dynamisk. Igjen, dette er helt forståelig når React abstraherer bort den tradisjonelle tilnærmingen du kanskje har strekt deg etter. CSSOM er sannsynligvis ikke noe du trenger i ditt daglige arbeid. Men det er sannsynlig at du må samhandle med det på et tidspunkt, selv i et engangstilfelle. Disse erfaringene inspirerte meg til å skrive denne artikkelen. Det er mange eksisterende nettfunksjoner og teknologier i naturen som du kanskje aldri berører direkte i det daglige arbeidet ditt. Kanskje du er ganske ny på nettutvikling og rett og slett ikke er klar over dem fordi du er gjennomsyret av abstraksjonen av et spesifikt rammeverk som ikke krever at du kjenner det dypt, eller til og med i det hele tatt. Jeg snakker spesifikt om XML, som mange av oss vet er et eldgammelt språk som ikke er helt ulikt HTML. Jeg tar dette opp på grunn av nylige WHATWG-diskusjoner som antyder at en betydelig del av XML-stakken kjent som XSLT-programmering bør fjernes fra nettlesere. Dette er akkurat den typen eldre, eksisterende teknologi vi har hatt i årevis som kan brukes til noe så praktisk som CSSOM-situasjonen teamet mitt var i. Har du jobbet med XSLT før? La oss se om vi lener oss tungt inn i denne eldre teknologien og utnytter funksjonene utenfor XML-sammenheng for å takle reelle problemer i dag. XPath: The Central API Den viktigste XML-teknologien som kanskje er den mest nyttige utenfor et rett XML-perspektiv er XPath, et spørringsspråk som lar deg finne hvilken som helst node eller attributt i et markup-tre med ett rotelement. Jeg har en personlig hengivenhet for XSLT, men det er også avhengig av XPath, og personlig hengivenhet må legges til side når det gjelder rangering av betydning. Argumentet for å fjerne XSLT nevner ikke XPath, så jeg antar at det fortsatt er tillatt. Det er bra fordi XPath er det sentrale og viktigste API-et i denne pakken med teknologier, spesielt når du prøver å finne noe å bruke utenfor normal XML-bruk. Det er viktig fordi mens CSS-velgere kan brukes til å finne de fleste elementene på siden din, kan de ikke finne dem alle. Videre kan ikke CSS-velgere brukes til å finne et element basert på dets nåværende posisjon i DOM. XPath kan. Nå, noen av dere som leser dette kjenner kanskje XPath, og noen kanskje ikke. XPath er et ganske stort område av teknologi, og jeg kan egentlig ikke lære alt det grunnleggende og også vise deg kule ting å gjøre med det i en enkelt artikkel som denne. Jeg prøvde faktisk å skrive den artikkelen, men den gjennomsnittlige Smashing Magazine-publikasjonen går ikke over 5000 ord. Jeg var allerede på mer enn2000 ord mens bare halvveis gjennom det grunnleggende. Så jeg skal begynne å gjøre kule ting med XPath og gi deg noen lenker som du kan bruke til det grunnleggende hvis du synes dette er interessant. Kombinere XPath og CSS XPath kan gjøre mange ting som CSS-velgere ikke kan når de spør etter elementer. Men CSS-velgere kan også gjøre noen få ting som XPath ikke kan, nemlig spørre elementer etter klassenavn.
CSS XPath .minKlasse /*[inneholder(@klasse, "minKlasse")]
I dette eksemplet spør CSS om elementer som inneholder et .myClass-klassenavn. I mellomtiden spør XPath-eksemplet om elementer som inneholder en attributtklasse med strengen "myClass". Med andre ord, den velger elementer med myClass i alle attributter, inkludert elementer med .myClass-klassenavnet – så vel som elementer med "myClass" i strengen, for eksempel .myClass2. XPath er bredere i den forstand. Så nei. Jeg foreslår ikke at vi bør kaste ut CSS og begynne å velge alle elementer via XPath. Det er ikke poenget. Poenget er at XPath kan gjøre ting som CSS ikke kan og fortsatt kan være svært nyttig, selv om det er en eldre teknologi i nettleserstakken og kanskje ikke virker opplagt ved første øyekast. La oss bruke de to teknologiene sammen, ikke bare fordi vi kan, men fordi vi vil lære noe om XPath i prosessen, noe som gjør det til et annet verktøy i stabelen din – et du kanskje ikke visste at har vært der hele tiden! Problemet er at JavaScripts document.evaluate-metode og de ulike spørringsvelgermetodene vi bruker med CSS API-ene for JavaScript er inkompatible. Jeg har laget et kompatibelt spørrings-API for å komme i gang, men jeg har riktignok ikke tenkt så mye på det siden det er en avvik fra det vi gjør her. Her er et ganske enkelt fungerende eksempel på en gjenbrukbar spørringskonstruktør: Se Pen-queryXPath [forked] av Bryan Rasmussen. Jeg har lagt til to metoder på dokumentobjektet: queryCSSSelectors (som egentlig er querySelectorAll) og queryXPaths. Begge disse returnerer et queryResults-objekt:
{ queryType: noder | streng | nummer | boolsk, resultater: alle[] // html-elementer, xml-elementer, strenger, tall, booleaner, queryCSSSelectors: (query: string, amend: boolean) => queryResults, queryXpaths: (query: string, amend: boolean) => queryResults }
queryCSSSelectors og queryXpaths-funksjonene kjører spørringen du gir dem over elementene i resultatmatrisen, så lenge resultatmatrisen er av typen noder, selvfølgelig. Ellers vil den returnere et queryResult med en tom matrise og en type noder. Hvis endringsegenskapen er satt til sann, vil funksjonene endre sine egne queryResults. Dette skal under ingen omstendigheter brukes i et produksjonsmiljø. Jeg gjør det på denne måten utelukkende for å demonstrere de ulike effektene av å bruke de to spørrings-API-ene sammen. Eksempelsøk Jeg vil vise noen eksempler på forskjellige XPath-spørringer som viser noen av de kraftige tingene de kan gjøre og hvordan de kan brukes i stedet for andre tilnærminger. Det første eksemplet er //li/text(). Dette spør etter alle li-elementer og returnerer tekstnodene deres. Så hvis vi skulle spørre etter følgende HTML:
- en
- to
- tre
… dette er hva som returneres:
{"queryType":"xpathEvaluate","results":["one","to","three"],"resultType":"string"}
Med andre ord får vi følgende array: ["one","to","tre"]. Normalt vil du spørre etter li-elementene for å få det, gjøre resultatet av spørringen om til en matrise, kartlegge matrisen og returnere tekstnoden til hvert element. Men vi kan gjøre det mer konsist med XPath: document.queryXPaths("//li/text()").resultater.
Legg merke til at måten å få en tekstnode på er å bruke text(), som ser ut som en funksjonssignatur – og det er det. Den returnerer tekstnoden til et element. I vårt eksempel er det tre li-elementer i markeringen, som hver inneholder tekst ("én", "to" og "tre").
La oss se på enda et eksempel på en tekst()-spørring. Anta at dette er vår markering:
La oss skrive en spørring som returnerer href-attributtverdien: document.queryXPaths("//a[text() = 'Logg på']/@href").results.
Dette er en XPath-spørring på gjeldende dokument, akkurat som det forrige eksemplet, men denne gangen returnerer vi href-attributtet til en lenke (et element) som inneholder teksten "Sign In". Den faktiske returnerteResultatet er ["/login.html"]. Oversikt over XPath-funksjoner Det finnes en rekke XPath-funksjoner, og du er sannsynligvis ikke kjent med dem. Det er flere, synes jeg, det er verdt å vite om, inkludert følgende:
starter-withHvis en tekst starter med et bestemt annen teksteksempel, returns-with(@href, 'http:') returnerer true hvis et href-attributt starter med http:. containsIf en tekst inneholder et bestemt annen teksteksempel, returnerer contains(text(), "Smashing Magazine") sant hvis en tekstnode inneholder ordene "Smashing Magazine" hvor som helst. count Returnerer en telling av hvor mange treff det er til en spørring. For eksempel returnerer count(//*[starts-with(@href, 'http:']) en telling av hvor mange lenker i kontekstnoden som har elementer med et href-attributt som inneholder teksten som begynner med http:. substring Fungerer som JavaScript-substring, bortsett fra at du sender strengen som et argument. For eksempel, substring("min tekst", 2, 4) returnerer "y t". substring-beforeReturnerer delen av en streng før en annen streng. For eksempel, substing-before("min tekst", " ") returnerer "min". På samme måte returnerer substring-before("hei","bye") en tom streng. substring-afterReturnerer delen av en streng etter en annen streng. For eksempel, substing-after("min tekst", " ") returnerer "tekst". På samme måte returnerer substring-after("hei","bye") en tom streng. normalize-space Returnerer argumentstrengen med mellomrom normalisert ved å fjerne innledende og etterfølgende mellomrom og erstatte sekvenser av mellomrom med et enkelt mellomrom. returnerer ikke en boolsk sann hvis argumentet er usant, ellers usant. true Returnerer boolsk sant. falseReturnerer boolesk false. concatDet samme som JavaScript concat, bortsett fra at du ikke kjører det som en metode på en streng. I stedet legger du inn alle strengene du vil sette sammen. string-lengthDette er ikke det samme som JavaScript string-length, men returnerer heller lengden på strengen den er gitt som argument. translateThis tar en streng og endrer det andre argumentet til det tredje argumentet. For eksempel, translate("abcdef", "abc", "XYZ") gir ut XYZdef.
Bortsett fra disse spesielle XPath-funksjonene, er det en rekke andre funksjoner som fungerer akkurat på samme måte som deres JavaScript-motstykker - eller motstykker i stort sett alle programmeringsspråk - som du sannsynligvis også vil finne nyttige, for eksempel gulv, tak, rund, sum, og så videre. Følgende demo illustrerer hver av disse funksjonene: Se Pen XPath Numeriske funksjoner [forked] av Bryan Rasmussen. Legg merke til at, som de fleste av strengmanipulasjonsfunksjonene, tar mange av de numeriske en enkelt inngang. Dette er selvfølgelig fordi de skal brukes til spørring, som i det siste XPath-eksemplet: //li[gulv(tekst()) > 250]/@val
Hvis du bruker dem, som de fleste eksemplene gjør, vil du ende opp med å kjøre den på den første noden som samsvarer med banen. Det er også noen typekonverteringsfunksjoner du sannsynligvis bør unngå fordi JavaScript allerede har sine egne typekonverteringsproblemer. Men det kan være tider når du vil konvertere en streng til et tall for å kontrollere den mot et annet tall. Funksjoner som angir typen av noe er boolsk, tall, streng og node. Dette er de viktige XPath-datatypene. Og som du kanskje forestiller deg, kan de fleste av disse funksjonene brukes på datatyper som ikke er DOM-noder. For eksempel tar substring-after en streng som vi allerede har dekket, men det kan være strengen fra et href-attributt. Det kan også bare være en streng:
const testSubstringAfter = document.queryXPaths("substring-after('hei verden',' ')");
Selvfølgelig vil dette eksemplet gi oss tilbake resultatmatrisen som ["verden"]. For å vise dette i aksjon har jeg laget en demoside som bruker funksjoner mot ting som ikke er DOM-noder: Se Pen-queryXPath [forked] av Bryan Rasmussen. Du bør merke deg det overraskende aspektet ved oversettelsesfunksjonen, som er at hvis du har et tegn i det andre argumentet (dvs. listen over tegn du vil ha oversatt) og ikke noe samsvarende tegn å oversette til, blir det tegnet fjernet fra utdataene. Altså dette:
translate('Hei, mitt navn er Inigo Montoya, du drepte faren min, forbered deg på å dø','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*')
…resultater i strengen, inkludert mellomrom: [" * * ** "]
Dette betyr at bokstaven "a" blir oversatt til en stjerne (*), men alle andre tegn som ikke har en oversettelse gitt målstrengen blir fullstendig fjernet. Mellomrommet er alt vi har igjenmellom de oversatte "a"-tegnene. Så igjen, denne spørringen:
translate('Hei, mitt navn er Inigo Montoya, du drepte faren min, forbered deg på å dø','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*******************************************************')")
…har ikke problemet og gir et resultat som ser slik ut:
"***** ** **** ** ***** ******* *** ****** ** ****** ******* ** ***"
Det kan slå deg at det ikke er noen enkel måte i JavaScript å gjøre akkurat det XPath-oversettelsesfunksjonen gjør, selv om for mange brukstilfeller kan replaceAll med regulære uttrykk håndtere det. Du kan bruke samme tilnærming som jeg har vist, men det er suboptimalt hvis alt du vil er å oversette strengene. Følgende demo omslutter XPaths oversettelsesfunksjon for å gi en JavaScript-versjon: Se Penneoversettelsesfunksjonen [forked] av Bryan Rasmussen. Hvor kan du bruke noe slikt? Vurder Caesar Cipher-kryptering med en tre-plassers offset (f.eks. top-of-the-line kryptering fra 48 f.Kr.):
translate("Cæsar planlegger å krysse Rubicon!", "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz", "XYZABCDEFGHIJKLMNOPQRSTUVWxyzabcdefghijklmnopqrstuvw")
Inngangsteksten "Caesar planlegger å krysse Rubicon!" resulterer i "Zxbpxo fp mixkkfkd ql zolpp qeb Oryfzlk!" For å gi et annet raskt eksempel på forskjellige muligheter, laget jeg en metallfunksjon som tar en strenginndata og bruker en oversettelsesfunksjon for å returnere teksten, inkludert alle tegn som tar omlyd. Se pennens metallfunksjon [forked] av Bryan Rasmussen.
const metall = (str) => { return translate(str, "AOUaou","ÄÖÜäöü"); }
Og hvis du får teksten "Motley Crue ruler, rock on dudes!", returnerer "Mötley Crüe rüles, röck ön düdes!" Det er klart at man kan ha alle slags parodier av denne funksjonen. Hvis det er deg, burde denne TVTropes-artikkelen gi deg mye inspirasjon. Bruke CSS med XPath Husk hovedgrunnen vår for å bruke CSS-velgere sammen med XPath: CSS forstår ganske mye hva en klasse er, mens det beste du kan gjøre med XPath er strengsammenligninger av klasseattributtet. Det vil fungere i de fleste tilfeller. Men hvis du noen gang skulle havne i en situasjon der for eksempel noen opprettet klasser kalt .primaryLinks og .primaryLinks2 og du brukte XPath for å få .primaryLinks-klassen, ville du sannsynligvis få problemer. Så lenge det ikke er noe dumt sånt, vil du sannsynligvis bruke XPath. Men jeg er trist å rapportere at jeg har jobbet på steder der folk gjør slike dumme ting. Her er en annen demo som bruker CSS og XPath sammen. Den viser hva som skjer når vi bruker koden til å kjøre en XPath på en kontekstnode som ikke er dokumentets node. Se Pen css og xpath sammen [forked] av Bryan Rasmussen. CSS-spørringen er .relatedarticles a, som henter de to a-elementene i en div som er tildelt en .relatedarticles-klasse. Etter det kommer tre "dårlige" spørringer, det vil si spørringer som ikke gjør det vi vil at de skal gjøre når de kjører med disse elementene som kontekstnoden. Jeg kan forklare hvorfor de oppfører seg annerledes enn du kanskje forventer. De tre dårlige spørsmålene det er snakk om er:
//tekst(): Returnerer all teksten i dokumentet. //a/text(): Returnerer all teksten inne i lenker i dokumentet. ./a/text(): Returnerer ingen resultater.
Årsaken til disse resultatene er at mens konteksten din er et element som returneres fra CSS-søket, går // mot hele dokumentet. Dette er styrken til XPath; CSS kan ikke gå fra en node opp til en stamfar og deretter til en søsken til den forfaren, og gå ned til en etterkommer av den søsken. Men XPath kan. I mellomtiden spør ./ barna til den gjeldende noden, der prikken (.) representerer gjeldende node, og skråstreken (/) representerer å gå til en underordnet node – om det er et attributt, et element eller en tekst bestemmes av neste del av banen. Men det er ikke noe underordnet element valgt av CSS-spørringen, og derfor returnerer den heller ingenting. Det er tre gode spørsmål i den siste demoen:
.//text(), ./tekst(), normalize-space(./text()).
Normalize-space-spørringen demonstrerer XPath-funksjonsbruk, men fikser også et problem inkludert i de andre spørringene. HTML er strukturert slik:
Automatiser funksjonstesten din med Selenium WebDriver
Spørringen returnerer en linjemating på begynnelsen og slutten av tekstnoden,og normalize-space fjerner dette. Å bruke en hvilken som helst XPath-funksjon som returnerer noe annet enn en boolsk med en XPath-inndata, gjelder for andre funksjoner. Følgende demo viser en rekke eksempler: Se eksempler på Pen xpath-funksjoner [forked] av Bryan Rasmussen. Det første eksemplet viser et problem du bør se opp for. Nærmere bestemt følgende kode:
document.queryXPaths("substring-after(//a/@href,'https://')");
… returnerer én streng:
"www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/"
Det gir mening, ikke sant? Disse funksjonene returnerer ikke matriser, men snarere enkeltstrenger eller enkelttall. Å kjøre funksjonen hvor som helst med flere resultater returnerer bare det første resultatet. Det andre resultatet viser hva vi virkelig ønsker:
document.queryCSSSelectors("a").queryXPaths("substring-after(./@href,'https://')");
Som returnerer en matrise med to strenger:
["www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/","www.smashingmagazine.com/2022/11/automated-test-results-improve-accessibility/"]
XPath-funksjoner kan nestes akkurat som funksjoner i JavaScript. Så hvis vi kjenner URL-strukturen til Smashing Magazine, kan vi gjøre følgende (det anbefales å bruke bokstavmaler): `oversett( delstreng( substring-after(./@href, 'www.smashingmagazine.com/') ,9), '/','')'
Dette blir litt for komplekst i den grad at det trenger kommentarer som beskriver hva det gjør: ta hele URL-en fra href-attributtet etter www.smashingmagazine.com/, fjern de ni første tegnene, og oversett deretter skråstreken (/) til ingenting for å bli kvitt den avsluttende skråstreken. Den resulterende matrisen:
["feature-testing-selenium-webdriver","automated-test-results-improve-accessibility"]
Flere XPath-brukssaker XPath kan virkelig skinne i testing. Årsaken er ikke vanskelig å se, da XPath kan brukes til å hente hvert element i DOM, fra hvilken som helst posisjon i DOM, mens CSS ikke kan. Du kan ikke regne med at CSS-klasser forblir konsistente i mange moderne byggesystemer, men med XPath er vi i stand til å lage mer robuste treff på hva tekstinnholdet i et element er, uavhengig av en endret DOM-struktur. Det har vært forskning på teknikker som lar deg lage spenstige XPath-tester. Ingenting er verre enn at tester flakes ut og mislykkes bare fordi en CSS-velger ikke lenger fungerer fordi noe har fått nytt navn eller fjernet. XPath er også veldig bra på utvinning av flere lokatorer. Det er mer enn én måte å bruke XPath-spørringer for å matche et element. Det samme gjelder med CSS. Men XPath-spørringer kan bore inn i ting på en mer målrettet måte som begrenser hva som returneres, slik at du kan finne et spesifikt samsvar der det kan være flere mulige samsvar. For eksempel kan vi bruke XPath til å returnere et spesifikt h2-element som er inneholdt i en div som umiddelbart følger en søsken-div som igjen inneholder et underordnet bildeelement med et data-testID="leader"-attributt på:
forstår ikke denne overskriften
Ikke skjønner denne overskriften heller
Overskriften for lederbildet
Dette er spørringen: document.queryXPaths(` //div[ følgende søsken::div[1] /img[@data-testID='leder'] ] /h2/ tekst() `);
La oss ta en demo for å se hvordan det hele henger sammen: Se Pen Complex H2 Query [forked] av Bryan Rasmussen. Så ja. Det er mange mulige veier til ethvert element i en test som bruker XPath. XSLT 1.0 Avvikling Jeg nevnte tidlig at Chrome-teamet planlegger å fjerne XSLT 1.0-støtte fra nettleseren. Det er viktig fordi XSLT 1.0 bruker XML-fokusert programmering for dokumenttransformasjon som igjen er avhengig av XPath 1.0, som er det som finnes i de fleste nettlesere. Når det skjer, mister vi en nøkkelkomponent i XPath. Men gitt det faktum at XPath er veldig bra for å skrive tester, finner jeg det usannsynlig at XPath som helhet vil forsvinne når som helst snart. Når det er sagt, har jeg lagt merke til at folk blir interessert i en funksjon når den blir tatt bort. Og det er absolutt sant i tilfelle XSLT 1.0 blir avviklet. Det foregår en hel diskusjon på Hacker News fylt med argumenter mot avskrivningen. Innlegget i seg selv er et godt eksempel på å lage et blogging-rammeverk med XSLT. Dukan lese diskusjonen selv, men det kommer inn på hvordan JavaScript kan brukes som et shim for XLST for å håndtere den slags saker. Jeg har også sett forslag om at nettlesere bør bruke SaxonJS, som er en port til JavaScripts Saxon XSLT-, XQUERY- og XPath-motorer. Det er en interessant idé, spesielt ettersom Saxon-JS implementerer den nåværende versjonen av disse spesifikasjonene, mens det ikke er noen nettleser som implementerer noen versjon av XPath eller XSLT utover 1.0, og ingen som implementerer XQuery. Jeg tok kontakt med Norm Tovey-Walsh hos Saxonica, selskapet bak SaxonJS og andre versjoner av Saxon-motoren. Han sa: "Hvis en nettleserleverandør var interessert i å ta SaxonJS som utgangspunkt for å integrere moderne XML-teknologier i nettleseren, ville vi bli glade for å diskutere det med dem." - Norm Tovey-Walsh
Men la også til: "Jeg ville bli veldig overrasket om noen trodde at det å ta SaxonJS i sin nåværende form og slippe det inn i nettleserbygget uendret ville være den ideelle tilnærmingen. En nettleserleverandør kan, på grunn av det faktum at de bygger nettleseren, nærme seg integrasjonen på et mye dypere nivå enn vi kan "fra utsiden." - Norm Tovey-Walsh
Det er verdt å merke seg at Tovey-Walshs kommentarer kom omtrent en uke før XSLT-avviklingskunngjøringen. Konklusjon Jeg kunne fortsette og fortsette. Men jeg håper dette har demonstrert kraften til XPath og gitt deg mange eksempler som viser hvordan du bruker det for å oppnå store ting. Det er et perfekt eksempel på eldre teknologi i nettleserstakken som fortsatt har mye nytte i dag, selv om du aldri har visst at den eksisterte eller aldri har vurdert å strekke deg etter den. Videre lesing
"Enhancing the Resiliency of Automated Web Tests with Natural Language" (ACM Digital Library) av Maroun Ayli, Youssef Bakouny, Nader Jalloul og Rima KilanyDenne artikkelen gir mange XPath-eksempler for å skrive spenstige tester. XPath (MDN) Dette er et utmerket sted å starte hvis du vil ha en teknisk forklaring som beskriver hvordan XPath fungerer. XPath Tutorial (ZVON) Jeg har funnet ut at denne opplæringen er den mest nyttige i min egen læring, takket være et vell av eksempler og klare forklaringer. XPatherDette interaktive verktøyet lar deg jobbe direkte med koden.
