He estado en desarrollo front-end el tiempo suficiente para ver una tendencia a lo largo de los años: desarrolladores más jóvenes que trabajan con un nuevo paradigma de programación sin comprender su contexto histórico. Por supuesto, es perfectamente comprensible no saber algo. La Web es un lugar muy grande con un conjunto diverso de habilidades y especialidades, y no siempre sabemos lo que no sabemos. El aprendizaje en este campo es un viaje continuo y no algo que sucede una vez y termina. Caso en cuestión: alguien de mi equipo preguntó si era posible saber si los usuarios navegaban fuera de una pestaña en particular en la interfaz de usuario. Señalé el evento beforeunload de JavaScript. Pero aquellos que han abordado esto antes saben que esto es posible porque han recibido alertas sobre datos no guardados en otros sitios, para los cuales beforeunload es un caso de uso típico. También le señalé los eventos de cambio de visibilidad y ocultación de página a mi colega por si acaso. ¿Cómo supe de eso? Porque surgió en otro proyecto, no porque lo estudié cuando aprendí JavaScript inicialmente. El hecho es que los frameworks front-end modernos están sobre los hombros de los gigantes tecnológicos que los precedieron. Abstraen las prácticas de desarrollo, a menudo para una mejor experiencia del desarrollador que reduce, o incluso elimina, la necesidad de conocer o tocar lo que tradicionalmente han sido conceptos front-end esenciales que todos probablemente deberían conocer. Considere el modelo de objetos CSS (CSSOM). Se podría esperar que cualquiera que trabaje en CSS y JavaScript tenga mucha experiencia práctica en CSSOM, pero ese no siempre será el caso. Había un proyecto de React para un sitio de comercio electrónico en el que trabajé donde necesitábamos cargar una hoja de estilo para el proveedor de pagos seleccionado actualmente. El problema era que la hoja de estilo se cargaba en cada página cuando realmente solo era necesaria en una página específica. El desarrollador encargado de hacer que esto sucediera nunca había cargado una hoja de estilo dinámicamente. Nuevamente, esto es totalmente comprensible cuando React abstrae el enfoque tradicional que podría haber elegido. Es probable que el CSSOM no sea algo que necesite en su trabajo diario. Pero es probable que necesites interactuar con él en algún momento, incluso en un caso puntual. Estas experiencias me inspiraron a escribir este artículo. Hay muchas funciones y tecnologías web existentes que quizás nunca toques directamente en tu trabajo diario. Quizás eres bastante nuevo en el desarrollo web y simplemente no los conoces porque estás inmerso en la abstracción de un marco específico que no requiere que lo conozcas en profundidad, o incluso que no lo conozcas en absoluto. Me refiero específicamente a XML, que muchos de nosotros sabemos que es un lenguaje antiguo no totalmente diferente de HTML. Menciono esto debido a discusiones recientes de WHATWG que sugieren que una parte importante de la pila XML conocida como programación XSLT debería eliminarse de los navegadores. Este es exactamente el tipo de tecnología más antigua que hemos tenido durante años y que podría usarse para algo tan práctico como la situación CSSOM en la que se encontraba mi equipo. ¿Has trabajado con XSLT antes? Veamos si nos apoyamos mucho en esta tecnología más antigua y aprovechamos sus características fuera del contexto de XML para abordar los problemas del mundo real actual. XPath: la API central La tecnología XML más importante y quizás la más útil fuera de una perspectiva XML directa es XPath, un lenguaje de consulta que le permite encontrar cualquier nodo o atributo en un árbol de marcado con un elemento raíz. Tengo un afecto personal por XSLT, pero eso también depende de XPath, y el afecto personal debe dejarse de lado al clasificar la importancia. El argumento para eliminar XSLT no menciona XPath, por lo que supongo que todavía está permitido. Eso es bueno porque XPath es la API central y más importante en este conjunto de tecnologías, especialmente cuando se intenta encontrar algo para usar fuera del uso normal de XML. Es importante porque, si bien los selectores CSS se pueden utilizar para encontrar la mayoría de los elementos de su página, no pueden encontrarlos todos. Además, los selectores CSS no se pueden utilizar para encontrar un elemento en función de su posición actual en el DOM. XPath puede. Ahora bien, es posible que algunos de los que lean esto conozcan XPath y otros no. XPath es un área de tecnología bastante amplia y realmente no puedo enseñar todos los conceptos básicos y también mostrarte cosas interesantes que hacer con él en un solo artículo como este. De hecho, intenté escribir ese artículo, pero la publicación promedio de Smashing Magazine no supera las 5000 palabras. ya estaba en más de2000 palabras y solo la mitad de lo básico. Entonces, comenzaré a hacer cosas interesantes con XPath y te daré algunos enlaces que puedes usar para los conceptos básicos si encuentras esto interesante. Combinando XPath y CSS XPath puede hacer muchas cosas que los selectores de CSS no pueden hacer al consultar elementos. Pero los selectores de CSS también pueden hacer algunas cosas que XPath no puede, es decir, consultar elementos por nombre de clase.
CSS XPath .miClase /*[contiene(@clase, "miClase")]
En este ejemplo, CSS consulta elementos que contienen un nombre de clase .myClass. Mientras tanto, el ejemplo XPath consulta elementos que contienen una clase de atributo con la cadena "myClass". En otras palabras, selecciona elementos con myClass en cualquier atributo, incluidos elementos con el nombre de clase .myClass, así como elementos con "myClass" en la cadena, como .myClass2. XPath es más amplio en ese sentido. Entonces no. No estoy sugiriendo que debamos descartar CSS y comenzar a seleccionar todos los elementos a través de XPath. Ese no es el punto. El punto es que XPath puede hacer cosas que CSS no puede y aún podría ser muy útil, aunque es una tecnología más antigua en la pila del navegador y puede no parecer obvia a primera vista. Usemos las dos tecnologías juntas no solo porque podemos, sino porque aprenderemos algo sobre XPath en el proceso, convirtiéndolo en otra herramienta en su pila, ¡una que quizás no sabía que estuvo ahí todo el tiempo! El problema es que el método document.evaluate de JavaScript y los diversos métodos de selección de consultas que utilizamos con las API de CSS para JavaScript son incompatibles. Creé una API de consulta compatible para comenzar, aunque es cierto que no he pensado mucho en ello ya que es una desviación de lo que estamos haciendo aquí. A continuación se muestra un ejemplo funcional bastante sencillo de un constructor de consultas reutilizable: Consulte Pen queryXPath [bifurcado] de Bryan Rasmussen. Agregué dos métodos en el objeto del documento: queryCSSSelectors (que es esencialmente querySelectorAll) y queryXPaths. Ambos devuelven un objeto queryResults:
{ tipo de consulta: nodos | cadena | número | booleano, resultados: cualquiera[] // elementos html, elementos xml, cadenas, números, booleanos, queryCSSSelectors: (consulta: cadena, modificar: booleano) => queryResults, queryXpaths: (consulta: cadena, modificación: booleano) => queryResults }
Las funciones queryCSSSelectors y queryXpaths ejecutan la consulta que les proporciona sobre los elementos en la matriz de resultados, siempre que la matriz de resultados sea de tipo nodos, por supuesto. De lo contrario, devolverá un queryResult con una matriz vacía y un tipo de nodos. Si la propiedad de modificación se establece en verdadero, las funciones cambiarán sus propios resultados de consulta. Bajo ninguna circunstancia se debe utilizar esto en un entorno de producción. Lo hago de esta manera simplemente para demostrar los diversos efectos del uso de las dos API de consulta juntas. Consultas de ejemplo Quiero mostrar algunos ejemplos de diferentes consultas XPath que demuestran algunas de las cosas poderosas que pueden hacer y cómo pueden usarse en lugar de otros enfoques. El primer ejemplo es //li/text(). Esto consulta todos los elementos li y devuelve sus nodos de texto. Entonces, si tuviéramos que consultar el siguiente HTML:
- uno
- dos
- tres
…esto es lo que se devuelve:
{"queryType":"xpathEvaluate","results":["uno","dos","tres"],"resultType":"string"}
En otras palabras, obtenemos la siguiente matriz: ["uno","dos","tres"]. Normalmente, consultaría los elementos li para obtener eso, convertiría el resultado de esa consulta en una matriz, asignaría la matriz y devolvería el nodo de texto de cada elemento. Pero podemos hacerlo de forma más concisa con XPath: document.queryXPaths("//li/text()").resultados.
Observe que la forma de obtener un nodo de texto es usar text(), que parece la firma de una función, y lo es. Devuelve el nodo de texto de un elemento. En nuestro ejemplo, hay tres elementos li en el marcado, cada uno de los cuales contiene texto ("uno", "dos" y "tres").
Veamos un ejemplo más de una consulta text(). Supongamos que este es nuestro marcado:
Escribamos una consulta que devuelva el valor del atributo href: document.queryXPaths("//a[text() = 'Iniciar sesión']/@href").resultados.
Esta es una consulta XPath en el documento actual, como el último ejemplo, pero esta vez devolvemos el atributo href de un enlace (un elemento) que contiene el texto "Iniciar sesión". El real devueltoEl resultado es ["/login.html"]. Descripción general de las funciones XPath Hay varias funciones XPath y probablemente no esté familiarizado con ellas. Creo que hay varios que vale la pena conocer, incluidos los siguientes:
comienza con Si un texto comienza con otro ejemplo de texto en particular, comienza con (@href, 'http:') devuelve verdadero si un atributo href comienza con http:. contiene Si un texto contiene otro ejemplo de texto en particular, contiene (texto(), "Smashing Magazine") devuelve verdadero si un nodo de texto contiene las palabras "Smashing Magazine" en cualquier lugar. countDevuelve un recuento de cuántas coincidencias hay para una consulta. Por ejemplo, count(//*[starts-with(@href, 'http:']) devuelve un recuento de cuántos enlaces en el nodo de contexto tienen elementos con un atributo href que contiene el texto que comienza con http:. subcadenaFunciona como una subcadena de JavaScript, excepto que pasa la cadena como argumento. Por ejemplo, la subcadena ("mi texto", 2, 4) devuelve "y t". substring-before Devuelve la parte de una cadena antes de otra cadena. Por ejemplo, substing-before("mi texto", " ") devuelve "mi". De manera similar, substring-before ("hola", "adiós") devuelve una cadena vacía. substring-after Devuelve la parte de una cadena después de otra cadena. Por ejemplo, substing-after("mi texto", " ") devuelve "texto". De manera similar, substring-after("hola","bye") devuelve una cadena vacía. normalize-space Devuelve la cadena de argumento con espacios en blanco normalizados eliminando los espacios en blanco iniciales y finales y reemplazando secuencias de caracteres de espacios en blanco por un solo espacio. notDevuelve un valor booleano verdadero si el argumento es falso; en caso contrario, falso. verdaderoDevuelve booleano verdadero. falseDevuelve booleano falso. concatLo mismo que concat de JavaScript, excepto que no lo ejecuta como un método en una cadena. En su lugar, ingresa todas las cadenas que desea concatenar. longitud de cadena Esto no es lo mismo que longitud de cadena de JavaScript, sino que devuelve la longitud de la cadena que se proporciona como argumento. traducirEsto toma una cadena y cambia el segundo argumento al tercer argumento. Por ejemplo, traducir("abcdef", "abc", "XYZ") genera XYZdef.
Aparte de estas funciones XPath particulares, hay otras funciones que funcionan igual que sus contrapartes de JavaScript (o contrapartes en básicamente cualquier lenguaje de programación) que probablemente también le resulten útiles, como piso, techo, redondo, suma, etc. La siguiente demostración ilustra cada una de estas funciones: Consulte las funciones numéricas de Pen XPath [bifurcadas] de Bryan Rasmussen. Tenga en cuenta que, como la mayoría de las funciones de manipulación de cadenas, muchas de las numéricas requieren una sola entrada. Esto se debe, por supuesto, a que se supone que deben usarse para realizar consultas, como en el último ejemplo de XPath: //li[piso(texto()) > 250]/@val
Si los usa, como lo hacen la mayoría de los ejemplos, terminará ejecutándolos en el primer nodo que coincida con la ruta. También hay algunas funciones de conversión de tipos que probablemente deberías evitar porque JavaScript ya tiene sus propios problemas de conversión de tipos. Pero puede haber ocasiones en las que quieras convertir una cadena en un número para compararla con algún otro número. Las funciones que establecen el tipo de algo son booleanas, numéricas, de cadena y de nodo. Estos son los tipos de datos XPath importantes. Y como puedes imaginar, la mayoría de estas funciones se pueden usar en tipos de datos que no son nodos DOM. Por ejemplo, substring-after toma una cadena como ya hemos cubierto, pero podría ser la cadena de un atributo href. También puede ser simplemente una cadena:
const testSubstringAfter = document.queryXPaths("substring-after('hola mundo',' ')");
Obviamente, este ejemplo nos devolverá la matriz de resultados como ["mundo"]. Para mostrar esto en acción, he creado una página de demostración usando funciones en cosas que no son nodos DOM: Consulte Pen queryXPath [bifurcado] de Bryan Rasmussen. Debes tener en cuenta el aspecto sorprendente de la función de traducción, que es que si tienes un carácter en el segundo argumento (es decir, la lista de caracteres que deseas traducir) y no hay ningún carácter coincidente al que traducir, ese carácter se elimina de la salida. Así, esto:
traducir('Hola, mi nombre es Iñigo Montoya, mataste a mi padre, prepárate para morir','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*')
…da como resultado la cadena, incluidos los espacios: [" * * ** "]
Esto significa que la letra "a" se traduce a un asterisco (*), pero todos los demás caracteres que no tienen una traducción dada la cadena de destino se eliminan por completo. El espacio en blanco es todo lo que nos queda.entre los caracteres "a" traducidos. Por otra parte, esta consulta:
traducir('Hola, mi nombre es Iñigo Montoya, mataste a mi padre, prepárate para morir','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','***************************************************')")
…no tiene el problema y genera un resultado similar a este:
"***** ** **** ** ***** ******* *** ****** ** ****** ******* ** ***"
Puede que le parezca que no existe una manera fácil en JavaScript de hacer exactamente lo que hace la función de traducción XPath, aunque para muchos casos de uso, reemplazarTodo con expresiones regulares puede manejarlo. Podría utilizar el mismo enfoque que he demostrado, pero no es óptimo si lo único que desea es traducir las cadenas. La siguiente demostración incluye la función de traducción de XPath para proporcionar una versión de JavaScript: Vea la función de traducción de Pen [bifurcada] de Bryan Rasmussen. ¿Dónde podrías usar algo como esto? Considere el cifrado César con un desplazamiento de tres lugares (por ejemplo, cifrado de primera línea del 48 a. C.):
traducir ("¡César está planeando cruzar el Rubicón!", "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz", "XYZABCDEFGHIJKLMNOPQRSTUVWxyzabcdefghijklmnopqrstuvw")
El texto de entrada "¡César planea cruzar el Rubicón!" da como resultado “Zxbpxo fp mixkkfkd ql zolpp qeb Oryfzlk!” Para dar otro ejemplo rápido de diferentes posibilidades, creé una función metálica que toma una entrada de cadena y usa una función de traducción para devolver el texto, incluidos todos los caracteres que usan diéresis. Vea la función Pen metal [bifurcada] de Bryan Rasmussen.
metal constante = (cadena) => { return traducir(str, "AOUaou","ÄÖÜäöü"); }
Y, si se le da el texto “¡Motley Crüe gobierna, rock on dudes!”, devuelve “¡Mötley Crüe rüles, röck ön düdes!” Obviamente, se podrían tener todo tipo de usos parodias de esta función. Si ese es usted, entonces este artículo de TVTropes debería brindarle mucha inspiración. Usando CSS con XPath Recuerde nuestra razón principal para usar selectores CSS junto con XPath: CSS entiende bastante bien qué es una clase, mientras que lo mejor que puede hacer con XPath son comparaciones de cadenas del atributo de clase. Eso funcionará en la mayoría de los casos. Pero si alguna vez te encontraras con una situación en la que, digamos, alguien creara clases llamadas .primaryLinks y .primaryLinks2 y estuvieras usando XPath para obtener la clase .primaryLinks, entonces probablemente tendrías problemas. Mientras no haya nada tonto como eso, probablemente usarías XPath. Pero me entristece informar que he trabajado en lugares donde la gente hace ese tipo de tonterías. Aquí hay otra demostración que usa CSS y XPath juntos. Muestra lo que sucede cuando usamos el código para ejecutar un XPath en un nodo de contexto que no es el nodo del documento. Vea Pen css y xpath juntos [bifurcados] por Bryan Rasmussen. La consulta CSS es . relatedarticles a, que recupera los dos elementos a en un div al que se le ha asignado una clase . relatedarticles. Después de eso hay tres consultas "malas", es decir, consultas que no hacen lo que queremos que hagan cuando se ejecutan con estos elementos como nodo de contexto. Puedo explicar por qué se comportan de manera diferente a lo que cabría esperar. Las tres malas consultas en cuestión son:
//text(): Devuelve todo el texto del documento. //a/text(): Devuelve todo el texto dentro de los enlaces del documento. ./a/text(): No devuelve resultados.
El motivo de estos resultados es que, si bien su contexto son elementos devueltos por la consulta CSS, // va en contra de todo el documento. Éste es el punto fuerte de XPath; CSS no puede pasar de un nodo a un ancestro y luego a un hermano de ese ancestro, y descender hasta un descendiente de ese hermano. Pero XPath sí puede. Mientras tanto, ./ consulta los hijos del nodo actual, donde el punto (.) representa el nodo actual y la barra inclinada (/) representa ir a algún nodo hijo; ya sea un atributo, elemento o texto, lo determina la siguiente parte de la ruta. Pero no hay ningún elemento secundario seleccionado por la consulta CSS, por lo que esa consulta tampoco devuelve nada. Hay tres buenas consultas en esa última demostración:
.//texto(), ./texto(), normalizar-espacio(./text()).
La consulta de normalización del espacio demuestra el uso de la función XPath, pero también soluciona un problema incluido en las otras consultas. El HTML está estructurado así:
Automatización de las pruebas de funciones con Selenium WebDriver
La consulta devuelve un avance de línea al principio y al final del nodo de texto,y normalize-space elimina esto. El uso de cualquier función XPath que devuelva algo que no sea un booleano con un XPath de entrada se aplica a otras funciones. La siguiente demostración muestra varios ejemplos: Vea los ejemplos de funciones Pen xpath [bifurcados] de Bryan Rasmussen. El primer ejemplo muestra un problema al que debes prestar atención. Específicamente, el siguiente código:
document.queryXPaths("substring-after(//a/@href,'https://')");
...devuelve una cadena:
"www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/"
Tiene sentido, ¿verdad? Estas funciones no devuelven matrices sino cadenas o números únicos. Ejecutar la función en cualquier lugar con múltiples resultados solo devuelve el primer resultado. El segundo resultado muestra lo que realmente queremos:
document.queryCSSSelectors("a").queryXPaths("substring-after(./@href,'https://')");
Que devuelve una matriz de dos cadenas:
["www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/","www.smashingmagazine.com/2022/11/automated-test-results-improve-accessibility/"]
Las funciones XPath se pueden anidar al igual que las funciones en JavaScript. Entonces, si conocemos la estructura de URL de Smashing Magazine, podríamos hacer lo siguiente (se recomienda usar literales de plantilla): `traducir( subcadena ( subcadena-después (./@href, 'www.smashingmagazine.com/') ,9), '/','')`
Esto se está volviendo demasiado complejo en la medida en que necesita comentarios que describan lo que hace: tome toda la URL del atributo href después de www.smashingmagazine.com/, elimine los primeros nueve caracteres, luego traduzca el carácter de barra diagonal (/) a nada para deshacerse de la barra diagonal final. La matriz resultante:
["pruebas-de-funciones-selenium-webdriver","resultados-de-pruebas-automatizados-mejoran-la-accesibilidad"]
Más casos de uso de XPath XPath realmente puede brillar en las pruebas. La razón no es difícil de ver, ya que XPath se puede utilizar para obtener cada elemento del DOM, desde cualquier posición del DOM, mientras que CSS no. No se puede contar con que las clases CSS sigan siendo consistentes en muchos sistemas de compilación modernos, pero con XPath podemos hacer coincidencias más sólidas en cuanto a cuál es el contenido de texto de un elemento, independientemente de una estructura DOM cambiante. Se han realizado investigaciones sobre técnicas que permiten realizar pruebas XPath resilientes. No hay nada peor que que las pruebas fallen y fallen solo porque un selector de CSS ya no funciona porque se ha cambiado el nombre o se ha eliminado algo. XPath también es realmente excelente en la extracción de múltiples localizadores. Hay más de una forma de utilizar consultas XPath para hacer coincidir un elemento. Lo mismo ocurre con CSS. Pero las consultas XPath pueden profundizar en las cosas de una manera más específica que limita lo que se devuelve, lo que le permite encontrar una coincidencia específica donde puede haber varias coincidencias posibles. Por ejemplo, podemos usar XPath para devolver un elemento h2 específico contenido dentro de un div que sigue inmediatamente a un div hermano que, a su vez, contiene un elemento de imagen secundario con un atributo data-testID="leader":
no entiendas este titular
Tampoco entiendas este titular
El encabezado de la imagen líder
Esta es la consulta: documento.queryXPaths(` //div[ siguiente-hermano::div[1] /img[@data-testID='líder'] ] /h2/ texto() `);
Hagamos una demostración para ver cómo se combina todo eso: Consulte la consulta Pen Complex H2 [bifurcada] de Bryan Rasmussen. Entonces, sí. Hay muchas rutas posibles a cualquier elemento de una prueba utilizando XPath. XSLT 1.0 en desuso Mencioné desde el principio que el equipo de Chrome planea eliminar la compatibilidad con XSLT 1.0 del navegador. Esto es importante porque XSLT 1.0 utiliza programación centrada en XML para la transformación de documentos que, a su vez, se basa en XPath 1.0, que es lo que se encuentra en la mayoría de los navegadores. Cuando eso suceda, perderemos un componente clave de XPath. Pero dado el hecho de que XPath es realmente excelente para escribir pruebas, me parece poco probable que XPath en su conjunto desaparezca pronto. Dicho esto, he notado que la gente se interesa en una función cuando ésta se elimina. Y eso es ciertamente cierto en el caso de que XSLT 1.0 esté obsoleto. Hay toda una discusión en Hacker News llena de argumentos en contra de la desaprobación. La publicación en sí es un gran ejemplo de cómo crear un marco de blogs con XSLT. TúPuede leer la discusión usted mismo, pero explica cómo JavaScript podría usarse como un complemento para que XLST maneje ese tipo de casos. También he visto sugerencias de que los navegadores deberían usar SaxonJS, que es un puerto para los motores Saxon XSLT, XQUERY y XPath de JavaScript. Es una idea interesante, especialmente porque Saxon-JS implementa la versión actual de estas especificaciones, mientras que no existe ningún navegador que implemente ninguna versión de XPath o XSLT más allá de 1.0, ni ninguno que implemente XQuery. Me comuniqué con Norm Tovey-Walsh de Saxonica, la empresa detrás de SaxonJS y otras versiones del motor Saxon. Él dijo: "Si algún proveedor de navegador estuviera interesado en tomar SaxonJS como punto de partida para integrar tecnologías XML modernas en el navegador, estaríamos encantados de discutirlo con él".—Norm Tovey-Walsh
Pero también agregó: "Me sorprendería mucho si alguien pensara que tomar SaxonJS en su forma actual e incluirlo en la versión del navegador sin cambios sería el enfoque ideal. Un proveedor de navegador, por el hecho de que construye el navegador, podría abordar la integración a un nivel mucho más profundo que el que podemos alcanzar "desde fuera". "—Norm Tovey-Walsh
Vale la pena señalar que los comentarios de Tovey-Walsh se produjeron aproximadamente una semana antes del anuncio de la desactivación de XSLT. Conclusión Podría seguir y seguir. Pero espero que esto haya demostrado el poder de XPath y le haya brindado muchos ejemplos que demuestren cómo usarlo para lograr grandes cosas. Es un ejemplo perfecto de tecnología más antigua en la pila de navegadores que todavía tiene mucha utilidad hoy en día, incluso si nunca supo que existía o nunca consideró utilizarla. Lectura adicional
“Mejora de la resiliencia de las pruebas web automatizadas con lenguaje natural” (Biblioteca digital ACM) por Maroun Ayli, Youssef Bakouny, Nader Jalloul y Rima Kilany. Este artículo proporciona muchos ejemplos de XPath para escribir pruebas resilientes. XPath (MDN) Este es un excelente lugar para comenzar si desea una explicación técnica que detalle cómo funciona XPath. Tutorial XPath (ZVON) He descubierto que este tutorial es el más útil en mi propio aprendizaje, gracias a una gran cantidad de ejemplos y explicaciones claras. XPatherEsta herramienta interactiva te permite trabajar directamente con el código.
