Maximice sus localizadores de prueba frontales trucos CSS

Las pruebas automatizadas en el front-end son geniales. Podemos escribir una prueba de código para visitar una página, o cargar solo un componente, y hacer que ese código de prueba haga clic en cosas o escriba texto como lo haría el usuario, y luego hacer declaraciones sobre el estado de la aplicación después de las interacciones. Esto nos permite confirmar que todo lo descrito en las pruebas funciona como se esperaba en la aplicación.

Dado que esta publicación trata sobre uno de los componentes básicos de todas las pruebas de interfaz de usuario automatizadas, no asumo demasiado conocimiento previo. Siéntase libre de saltarse las primeras secciones si ya está familiarizado con los conceptos básicos.

Estructura de la prueba anterior

Hay un modelo clásico que es útil conocer al escribir pruebas: Arreglar, Actuar, Se dicePara las pruebas de front-end, esto se traduce en un archivo de prueba, que hace lo siguiente:

1. Organizar: Preparar las cosas para el examen. Visite una página determinada o instale un componente determinado con los accesorios correctos, burle de algún estado, lo que sea.
2. Acción: Haz algo con la aplicación. Haga clic en un botón, complete un formulario, etc. O no, para verificaciones de estado simples podemos omitir esto.
3. Afirmación: Revisa algunas cosas. ¿El envío de un formulario mostraba una nota de agradecimiento? ¿Envió los datos correctos al back-end con POST?

Al aclarar con qué interactuar y luego mas tarde que revisar Sobre la páginapodemos usar diferentes localizadores de elementos para centrarnos en las partes del DOM que necesitamos usar.

UN locador puede ser algo así como un identificador de elemento, un elemento de contenido de texto o un selector de CSS, como .blog-post o incluso article > div.container > div > div > p:nth-child(12)Cualquier cosa que pueda identificar este elemento para su corredor de prueba puede ser un localizador Como probablemente pueda ver en el último selector de CSS, los localizadores vienen en muchas variaciones.

A menudo evaluamos los localizadores en términos de ser frágil o estable. En general, queremos los localizadores de elementos más estables posibles, para que nuestra prueba siempre pueda encontrar el elemento que necesita, incluso si el código alrededor del elemento cambia con el tiempo. Dicho esto, maximizar la estabilidad a toda costa puede conducir a una redacción defensiva de las pruebas, lo que en realidad las debilita. Obtenemos el mayor valor al tener una combinación de fragilidad y estabilidad que está en línea con lo que queremos que nos interesen nuestras pruebas.

De esta manera, los localizadores de elementos son como cinta adhesiva. Deben ser muy fuertes en una dirección y fáciles de rasgar en la otra dirección. Nuestras pruebas deben mantenerse juntas y continuar aprobándose cuando se realizan cambios menores en la aplicación, pero deben fallar fácilmente cuando ocurren cambios importantes que entran en conflicto con lo que establecimos en la prueba.

Guía para principiantes sobre la prueba del localizador de extremos de elementos

Primero, supongamos que escribimos instrucciones para que una persona real haga su trabajo. Se acaba de contratar a un nuevo inspector de puertas en Gate Inspectors, Inc. Usted es su jefe y una vez que se presenten todos, debe darles instrucciones para verificar su primera puerta. Si quieres tener éxito, probablemente no escríbeles una nota como esta:

Pasa la casa amarilla, continúa hasta llegar al campo donde la cabra del amigo de la madre de Mike desapareció esta vez, luego gira a la izquierda y dime si la puerta frente a la casa de enfrente se abre o no.

Estas instrucciones son como usar un selector CSS largo o XPath como localizador. Es frágil, y ese es el "tipo malo de frágil". Si se vuelve a pintar la casa amarilla y repite los pasos, ya no podrá encontrar la puerta y puede decidir darse por vencido (o en este caso, la prueba falla).

Del mismo modo, si no conoce la situación con la cabra del amigo de la madre de Mike, no puede detenerse en el punto de referencia correcto para saber qué puerta revisar. Esto es lo que hace que el "frágil de mal aspecto" sea malo: la prueba puede romperse por cualquier motivo, y ninguno de estos tiene nada que ver con la usabilidad de la puerta.

Así que hagamos una prueba frontal diferente, que es mucho más estable. Después de todo, legalmente en esta área, todas las puertas a la vez deben tener números de serie únicos del fabricante:

Vaya a la puerta con el número de serie 1234 y verifique si se abre.

Es más como encontrar un artículo por su identificador. Es más estable y es sólo un paso. Se han eliminado todos los puntos de falla de la última prueba. Esta prueba solo fallará si la puerta con esta identificación no se abre como se esperaba.

Ahora resulta que, aunque no hay dos puertas Deber tener la misma identificación el mismo camino que en realidad no se aplica en ninguna parte Y un día otra puerta de camino resulta tener la misma identificación.

Entonces, la próxima vez que el inspector de puertas recién contratado fue a probar la puerta 1234, primero encontró la otra, y ahora están visitando la casa equivocada y revisando la cosa equivocada. La prueba puede fallar o algo peor: si esta puerta funciona como se esperaba, la prueba aún pasa, pero no prueba el objeto previsto. Proporciona falsa confianza. Continuará pasando, incluso si los ladrones de puertas robaron nuestra puerta de destino original en medio de la noche.

Después de un incidente como este, quedó claro que los números de identificación no eran tan estables como pensábamos. Así que pensamos un poco en el siguiente nivel y decidimos que en el interior de la puerta nos gustaría un número de identificación especial solo para la prueba. Enviaré una técnica para poner el número de identificación especial solo en este puerto. Las nuevas instrucciones de prueba se ven así:

Vaya a la puerta con ID de prueba "my-favorite-gate" y verifique si se abre.

Es como usar los populares. data-testid atributo. Atributos como este son geniales porque en el código es obvio que están destinados a pruebas automatizadas y no necesitan ser cambiados o eliminados. Mientras la puerta tenga este atributo, siempre encontrarás la puerta. Al igual que las identificaciones, la unicidad aún no se ha impuesto, pero es menos probable.

Esto es aproximadamente lo más lejos posible de la fragilidad y confirma la funcionalidad de la puerta. No dependemos de nada excepto del atributo que agregamos deliberadamente para la prueba. Pero aquí hay un pequeño problema...

Esta es una prueba de interfaz de usuario para la puerta, pero el localizador es algo que ningún usuario usaría para encontrar la puerta.

Esta es una oportunidad perdida, porque en este distrito imaginario resulta que las puertas deben tener impreso el número de la casa para que la gente pueda ver la dirección. Entonces, todas las puertas deben tener una etiqueta única frente a la persona y, si no, esto es un problema en sí mismo.

Al ubicar el portón con ID de prueba, si resulta que el portón está repintado y el número de la casa está tapado, nuestra prueba volverá a pasar. Pero el objetivo de la puerta es que la gente tenga acceso a la casa. En otras palabras, una puerta de trabajo que el usuario no puede encontrar sin embargo, debe ser una prueba fallida y queremos un localizador que sea capaz de detectar este problema.

Aquí hay otra omisión en esta instrucción de prueba para el inspector de puertas en su primer día:

Ve a la puerta de la casa número 40 y comprueba si se abre.

Éste utiliza un localizador que añade valor a prueba: depende de algo de lo que también dependen los usuarios, que es la etiqueta de la puerta. Vuelve a añadir una posible razón para que la prueba falle antes de llegar a la interacción que queremos probar, lo que a primera vista puede parecer malo, pero en este caso, dado que el localizador es importante desde el punto de vista del usuario, no debemos descartarlo. "Frágil." Si no se puede encontrar la puerta en su etiqueta, no importa si se abre o no, es el "buen tipo de frágil".

DOM importa

Muchos consejos de prueba de front-end nos dicen que evitemos escribir localizadores que dependan de la estructura del DOM. Esto significa que los desarrolladores pueden rediseñar componentes y páginas con el tiempo y dejar que las pruebas confirmen que los flujos de trabajo dirigidos por el usuario no se interrumpen sin tener que actualizar las pruebas para ponerse al día con la nueva estructura. Este principio es útil, pero lo cambiaría un poco para decir que debemos evitar escribir localizadores que dependan de inadecuado Estructura DOM en nuestras pruebas de front-end.

Para que una aplicación funcione correctamente, el DOM debe reflejar la naturaleza y estructura del contenido que se encuentra en pantalla en todo momento. Una de las razones de esto es la accesibilidad. DOM, que es correcto en este sentido, es mucho más fácil para que la tecnología de asistencia analice y describa correctamente a los usuarios que no ven el contenido que muestra el navegador. La estructura DOM y el HTML simple y antiguo marcan una gran diferencia en la independencia de los usuarios que confían en la tecnología de asistencia.

Hagamos una prueba frontal para enviar algo en el formulario de contacto a nuestra aplicación. Usaremos ciprés para esto, pero los principios de la selección del localizador se aplican estratégicamente a todos los marcos de prueba de front-end que usan DOM para ubicar elementos. Aquí encontramos elementos, ingresamos una prueba, enviamos el formulario y verificamos que se haya alcanzado el estado "gracias":

// 👎 Not recommended
cy.get('#name').type('Mark')
cy.get('#comment').type('test comment')
cy.get('.submit-btn').click()
cy.get('.thank-you').should('be.visible')

Hay todo tipo de declaraciones implícitas en estas cuatro líneas. cy.get() comprueba si el elemento existe en el DOM. La prueba fallará si el elemento no existe después de cierto tiempo mientras actúa como type y click asegúrese de que los elementos estén visibles, permitidos y sin obstáculos antes de tomar medidas.

Entonces, obtenemos mucho "gratis" incluso en una prueba simple como esta, pero también introdujimos algunos dependencias en cosas que (y nuestros usuarios) no están interesados. El identificador específico y las clases que estamos comprobando parecen lo suficientemente estables, especialmente en comparación con selectores como div.main > p:nth-child(3) > span.is-a-button o lo que sea Estos selectores largos son tan específicos que un pequeño cambio en DOM puede conducir a una prueba fallida porque no puedo encontrar el artículono porque la funcionalidad esté comprometida.

Pero incluso a nuestros criadores bajos les gusta #namevienen con tres problemas:

1. El número de identificación se puede cambiar o eliminar en el código, lo que ignora el elemento, especialmente si el formulario puede aparecer más de una vez por página. Es posible que deba generar un número de identificación único para cada instancia, y esto no es algo que podamos completar fácilmente por adelantado en una prueba.
2. Si hay más de una copia de un formulario en la página y tienen la misma identificación, debemos decidir qué formulario completar.
3. De hecho, no nos importa cuál es la ID desde el punto de vista del usuario, por lo que todas las afirmaciones incrustadas de alguna manera... ¿no se utilizan por completo?

Para los problemas uno y dos, la solución recomendada suele ser utilizar atributos de datos especiales en nuestro HTML, que se agregan exclusivamente para realizar pruebas. Esto es mejor porque nuestras pruebas ya no dependen de la estructura del DOM, y debido a que el desarrollador cambia el código alrededor de un componente, las pruebas continuarán ejecutándose sin necesidad de una actualización, siempre y cuando mantengan data-test="name-field" adjunto a la derecha input elemento.

Sin embargo, esto no resuelve el problema tres: todavía tenemos una prueba de interacción frontal que depende de algo que no tiene sentido para el usuario.

Localizadores significativos para elementos interactivos

Los localizadores de elementos tienen sentido cuando dependen de algo que realmente somos querer depender porque algo en el localizador es importante para la experiencia del usuario. En el caso de los elementos interactivos diría que el mejor selector a utilizar es el del elemento nombre accesible.Ideal es algo como esto:

// 👍 Recommended
cy.getByLabelText('Name').type('Mark')

Este ejemplo utiliza porLabelText Assistant desde Biblioteca de pruebas de Cypress. (De hecho, si está utilizando una biblioteca de prueba de cualquier forma, probablemente ya lo ayude a escribir localizadores accesibles como este).

Esto es útil porque ahora las comprobaciones integradas (que obtenemos de forma gratuita a través de cy.type() comando) incluyen la disponibilidad del campo de formulario. Todos los elementos interactivos deben tener un nombre accesible que esté expuesto a la tecnología de asistencia. Así es como, por ejemplo, un usuario de lector de pantalla sabrá cómo se llama el campo de formulario para ingresar la información requerida.

La forma de proporcionar este nombre de campo de formulario accesible suele ser a través de un label elemento asociado al campo por un identificador getByLabelText el comando Cypress Testing Library comprueba que el campo esté correctamente etiquetado, pero también que el propio campo sea un elemento al que se le permita tener una etiqueta. Por ejemplo, el siguiente HTML fallará correctamente antes type() se intenta mandar porque aunque un label presente, etiquetando un div es HTML no válido:

<!-- 👎 Not recommended  -->
<label for="my-custom-input">Editable DIV element:</label>
<div id="my-custom-input" contenteditable="true" />

Debido a que se trata de HTML no válido, el software de lectura de pantalla nunca podría asociar correctamente esta etiqueta con este campo. Para corregir esto, actualizaremos el etiquetado para usar genuino input elemento:

<!-- 👍 Recommended -->
<label for="my-real-input">Real input:</label>
<input id="my-real-input" type="text" />

Esto es genial. Ahora, si la prueba falla en este punto después de las ediciones realizadas en el DOM, no se debe a cambios inapropiados en la estructura de cómo se organizan los elementos, sino a que nuestros editores hicieron algo para romperlo parte del DOM en el que nuestras pruebas anteriores están explícitamente interesadas, esto realmente sería importante para los usuarios.

Localizadores semánticos de elementos no interactivos

Para elementos no interactivos necesitamos ponernos sombreros para pensar. Usemos un poco de juicio antes de volver a data-cy o data-test atributos que siempre estarán ahí para nosotros, si el DOM no importa en absoluto.

Antes de sumergirnos en los localizadores comunes, recordemos: el estado de DOM es nuestro Whole Thing ™ como desarrolladores web (al menos eso creo) y DOM administra UX para cualquiera que no experimente la página visualmente. Entonces, la mayoría de las veces puede haber algún elemento significativo que podríamos o deberíamos usar en el código que podemos incluir en un localizador de prueba.

Y si no, porque, digamos, el código de la aplicación es como contenedores compartidos div y spanprimero debemos considerar corregir el código de la aplicación mientras agregamos la prueba. De lo contrario, existe el riesgo de que nuestras pruebas sean válidas. especificar que los contenedores compartidos son esperados y deseados, lo que dificulta un poco que alguien modifique este componente para hacerlo más accesible.

Como vimos anteriormente, con los elementos que tradicionalmente consideramos interactivo, hay una regla bastante buena que es fácil de incorporar en nuestras pruebas anteriores: los elementos interactivos deben tener etiquetas destacadas correctamente asociadas con el elemento. Entonces, todo lo interactivo, cuando lo probamos, debe ser seleccionado por el DOM usando esta etiqueta obligatoria.

Para los elementos que no consideramos interactivos, como la mayoría de los elementos de representación de contenido que muestran fragmentos de texto que no sean puntos de referencia básicos como main - No desencadenaremos ninguna falla en la auditoría de Lighthouse si reunimos la mayor parte de nuestro contenido no interactivo. div o span contenedores Pero el etiquetado no será muy informativo o útil para la tecnología de asistencia porque no describe naturaleza y estructura del contenido de alguien que no puede verlo. (Para ver esto al extremo, echa un vistazo a la excelente publicación de blog de Manuel Matuzovic, "Construya el sitio más inaccesible posible con un resultado perfecto de Lighthouse".)

El HTML que mostramos es donde comunicamos información contextual importante a cualquiera que no perciba el contenido visualmente. HTML se usa para construir un DOM, DOM se usa para crear un navegador árbol de accesibilidady el árbol de accesibilidad es una API que las tecnologías de asistencia de todo tipo pueden usar para expresar el contenido y las acciones que puede realizar una persona con discapacidad usando nuestro software. El lector de pantalla es a menudo el primer ejemplo que viene a la mente, pero el árbol de accesibilidad puede ser utilizado por otras tecnologías, como pantallas que convierten páginas web en Braille, entre otras.

Las comprobaciones de accesibilidad automáticas no nos dirán si realmente hemos creado el código HTML correcto para el contenido. La "corrección" de HTML es el juicio que hacemos de los desarrolladores acerca de qué información creemos que debe incluirse en el árbol de accesibilidad.

Después de hacer esta llamada, podemos decidir cuánto es apropiado incluir en la prueba automatizada de front-end.

Digamos que decidimos que el contenedor con status ARIA role mantendrá "gracias" y el mensaje de error del formulario de contacto. Esto puede ser bueno para que un lector de pantalla pueda anunciar los comentarios sobre el éxito o el fracaso del formulario. Clases CSS de .thank-you y .error se puede utilizar para controlar la condición visual.

Si agregamos este elemento y queremos escribir una prueba de IU para él, podemos escribir una declaración como esta después de que la prueba complete el formulario y lo envíe:

// 👎 Not recommended
cy.get('.thank-you').should('be.visible')

O incluso una prueba que usa un selector frágil pero sin sentido como este:

// 👎 Not recommended
cy.get('[data-testid="thank-you-message"]').should('be.visible')

Ambos se pueden reescribir usando cy.contains():

// 👍 Recommended
cy.contains('[role="status"]', 'Thank you, we have received your message')
  .should('be.visible')

Esto confirmará que ha aparecido el texto esperado y que está en el tipo de contenedor correcto. En comparación con la prueba anterior, esta tiene un valor mucho mayor en términos de verificación de la funcionalidad real. Si falla una parte de esta prueba, nos gustaría saberlo, porque tanto el mensaje como el selector de elementos son importantes para nosotros y no deben cambiarse trivialmente.

Definitivamente obtuvimos algo de cobertura aquí sin mucho código adicional, pero también introdujimos un tipo diferente de fragilidad. Tenemos cadenas en inglés simple en nuestras pruebas, y eso significa que si el mensaje de "gracias" cambia a algo como "¡Gracias por conectarse!", esa prueba falla repentinamente. Es lo mismo con todas las demás pruebas. Escribir una etiqueta requieren la actualización de cada prueba dirigida a los elementos que usan esa etiqueta.

Podemos mejorar esto usando la misma fuente de verdad para estas cadenas en las pruebas de front-end como lo hacemos en nuestro código. Y si actualmente tenemos oraciones legibles por humanos incrustadas allí mismo en el HTML de nuestros componentes... bueno, ahora tenemos una razón para sacar esas cosas de allí.

Las cadenas legibles por humanos pueden ser los números mágicos del código de la interfaz de usuario

UN número mágico (o menos emocionante, "constante numérica sin nombre") es ese valor súper específico que a veces se ve en el código que es importante para el resultado final de un cálculo, como el buen viejo 1.023033 o algo como esto. Pero dado que este número tiene una etiqueta, su significado no está claro y no está claro lo que hace. Tal vez aplicar un impuesto. Tal vez compense un error que no conocemos. ¿Quién sabe?

De cualquier manera, lo mismo ocurre con las pruebas preliminares, y el consejo general es evitar los números mágicos debido a su falta de claridad. Las revisiones de código a menudo los atrapan y preguntan para qué es el número. ¿Podemos moverlo a una constante? Hacemos lo mismo si un valor necesita ser reutilizado en varios lugares. En lugar de repetir el valor en todas partes, podemos almacenarlo en una variable y usar la variable según sea necesario.

Al escribir interfaces de usuario a lo largo de los años, he visto contenido textual en HTML o archivos de plantilla muy similares a los números mágicos en otros contextos. Establecemos valores absolutos a lo largo de nuestro código, pero de hecho puede ser más útil almacenar estos valores en otro lugar e ingresarlos durante la construcción (o incluso a través de una API, según la situación).

Hay varias razones para esto:

1. Trabajé con clientes que querían gestionar todo desde un sistema de gestión de contenido. El contenido, incluso las etiquetas de los formularios y los mensajes de estado que no estaban presentes en el CMS, debían evitarse. Los clientes querían un control total, por lo que no cambiar el contenido requiere editar el código y volver a implementar el sitio. Eso tiene sentido; código y contenido son conceptos diferentes.
2. He trabajado en muchas bases de código multilingües, donde el texto completo debe descargarse a través de algún tipo de marco de internacionalización, como este:

<label for="name">
  <!-- prints "Name" in English but something else in a different language -->
  {{content[currentLanguage].contactForm.name}}
</label>

3. Cuando se trata de pruebas de front-end, nuestras pruebas de interfaz de usuario son mucho más estables si, en lugar de buscar un mensaje específico de "gracias" que codificamos firmemente en la prueba, hacemos algo como esto:

const text = content.en.contactFrom // we would do this once and all tests in the file can read from it

cy.contains(text.nameLabel, '[role="status"]').should('be.visible')

Cada situación es diferente, pero tener un sistema de constantes de cadena es una gran ventaja al escribir pruebas de IU estables y lo recomendaría. Entonces, si la traducción o el contenido dinámico se vuelven necesarios para nuestra situación, estaremos mucho mejor preparados para ello.

he escuchado buenos argumentos contra importar cadenas de texto en las pruebas. Por ejemplo, algunas pruebas de búsqueda son más legibles y generalmente mejores si la prueba en sí misma determina el contenido esperado independientemente de la fuente del contenido.

Eso es justo. Esto me convence menos, porque creo que el contenido debe estar controlado por un modelo de revisión/publicación editorial, y quiero que la prueba verifique si contenido esperado de la fuente fueron representados, no algunas cadenas específicas que eran correctas cuando se escribió la prueba. Pero mucha gente no está de acuerdo conmigo en esto, y yo digo que una vez que se entiende el compromiso dentro del equipo, cualquier elección es aceptable.

Sin embargo, sigue siendo una buena idea aislar el código del contenido en el front-end de manera más general. Y, a veces, incluso puede ser válido mezclar y combinar, como importar cadenas en nuestras pruebas de componentes y no importarlas en nuestras pruebas de un extremo a otro. algunos duplicación y ganar confianza en que nuestros componentes muestran el contenido correcto, al tiempo que cuentan con pruebas de front-end que confirman de forma independiente el texto esperado, en el sentido editorial dirigido al usuario.

Cuándo usar data-test localizadores

Selectores de CSS como [data-test="success-message"] siguen siendo útiles y pueden ser muy útiles cuando se usan intencionalmente en lugar de usarlos todo el tiempo. Si consideramos que no existe una forma significativa y accesible de orientar un elemento, data-test Los atributos siguen siendo la mejor opción. Son mucho mejores que, por ejemplo, depender de una coincidencia, como cualquier estructura DOM el día que escribe la prueba, y volver al "segundo elemento de la lista en el tercer div con una clase de card"Estilo de prueba.

También hay momentos en los que se espera que el contenido sea dinámico y no hay forma de que podamos tomar fácilmente cadenas de alguna fuente común de verdad para usar en nuestras pruebas. data-test el atributo nos ayuda a llegar al elemento específico que nos interesa. Todavía se puede combinar con una declaración de accesibilidad conveniente, por ejemplo:

cy.get('h2[data-test="intro-subheading"]')

Aquí queremos encontrar lo que hay data-test atributo en intro-subheadingpero todavía permitimos que nuestra prueba confirme que debe ser un h2 elemento si esto es lo que esperamos que sea data-test el atributo se usa para asegurarnos de que obtengamos el específico h2 nos importa, nadie más h2 esto puede estar en la página si por alguna razón contenido de esto h2 no se puede saber durante la prueba.

Incluso cuando conocemos el contenido, aún podemos usar atributos de datos para asegurarnos de que la aplicación muestre ese contenido en el lugar correcto:

cy.contains('h2[data-test="intro-subheading"]', 'Welcome to Testing!')

data-test los selectores también pueden ser útiles para llegar a una parte específica de la página y luego hacer declaraciones sobre ella. Esto podría verse así:

cy.get('article[data-test="ablum-card-blur-great-escape"]').within(() => {
  cy.contains('h2', 'The Great Escape').should('be.visible')
  cy.contains('p', '1995 Album by Blur').should('be.visible')
  cy.get('[data-test="stars"]').should('have.length', 5)
})

En este punto, estamos entrando en algunos matices porque puede haber otras buenas formas de orientar este contenido, eso es solo un ejemplo. Pero al final del día, es bueno preocuparse por detalles como dónde estamos, porque al menos tenemos cierta comprensión de las funciones de accesibilidad integradas en el HTML que estamos probando y queremos incluirlas en nuestras pruebas.

Cuando el DOM importa, pruébalo

Las pruebas de front-end son mucho más valiosas si tenemos cuidado con la forma en que le decimos a las pruebas con qué elementos interactuar y qué esperar del contenido. Necesitamos preferir nombres accesibles para apuntar a componentes interactivos, y necesitamos incluir nombres de elementos específicos, roles ARIA y así llamado para contenido no interactivo, si estas cosas son relevantes para la funcionalidad. Estos localizadores, cuando son prácticos, crean la combinación correcta de fuerza y ​​fragilidad.

Y por supuesto, hay todo lo demás. data-test.