En una prueba End-to-End que interactúa con una interfaz de usuario, la prueba necesita encontrar elementos: campos, botones, enlaces, mensajes, tablas, filas o secciones. La forma de ubicar esos elementos se conoce como selector.
Elegir buenos selectores es clave para la estabilidad. Una prueba puede estar bien pensada y aun así fallar si depende de elementos frágiles, como clases visuales cambiantes, posiciones en pantalla o textos que se modifican con frecuencia.
En este tema veremos qué hace confiable a un selector y cómo elegir identificadores adecuados para pruebas E2E.
Un selector es una forma de indicar qué elemento de la interfaz debe usar la prueba. Por ejemplo, un selector puede apuntar al botón "Comprar", al campo de correo electrónico o al mensaje de confirmación de una operación.
Si la prueba no puede encontrar el elemento correcto, no podrá interactuar con la aplicación ni verificar el resultado esperado.
Las interfaces cambian con frecuencia: se ajustan estilos, se reorganizan componentes, se cambian textos, se agregan contenedores o se modifican clases CSS. Si la prueba depende de esos detalles, puede fallar aunque el comportamiento del sistema siga siendo correcto.
Ejemplos de fallas por selectores frágiles:
Un buen selector reduce mantenimiento y evita fallas que no representan defectos reales.
Un selector frágil depende de detalles que no forman parte del comportamiento que queremos validar. Puede funcionar al principio, pero romperse con cambios menores.
| Selector frágil | Por qué es riesgoso |
|---|---|
| Posición del elemento | Puede cambiar si se agrega o reordena contenido. |
| Clases CSS de estilo | Cambian con rediseños sin afectar la funcionalidad. |
| Estructura HTML muy profunda | Se rompe al refactorizar componentes o contenedores. |
| Texto no contractual | Puede cambiar por redacción, traducción o ajustes de producto. |
| Elementos demasiado genéricos | Pueden coincidir con varios botones, enlaces o campos. |
Un selector confiable identifica un elemento de manera estable y significativa. Debe seguir funcionando aunque cambien detalles visuales no relevantes.
Características de un buen selector:
La estabilidad del selector debe pensarse como parte de la mantenibilidad de la prueba.
Una práctica habitual es agregar atributos específicos para pruebas, como data-testid, data-test o data-cy. Estos identificadores permiten ubicar elementos sin depender del diseño visual.
login-email, checkout-confirm o order-success-message.
Estos atributos no deberían usarse para estilos ni lógica de negocio. Su propósito es ayudar a las pruebas a encontrar elementos estables.
La calidad del nombre también importa. Un identificador confuso o demasiado genérico puede dificultar el mantenimiento.
| Menos recomendable | Más recomendable | Motivo |
|---|---|---|
button1 |
checkout-confirm-button |
El segundo expresa la acción del usuario. |
green-btn |
save-profile-button |
El color puede cambiar; la acción es más estable. |
msg |
payment-error-message |
El segundo indica qué mensaje se espera. |
row-3 |
order-row-12345 |
La posición cambia; la entidad es más clara. |
En algunas herramientas modernas, es posible seleccionar elementos por su rol accesible: botón, enlace, campo de texto, encabezado o nombre visible. Esto puede ser útil porque se parece a cómo un usuario interpreta la interfaz.
Ejemplos conceptuales:
Este enfoque mejora legibilidad y puede favorecer accesibilidad, pero depende de que los nombres visibles sean parte estable del contrato de la interfaz.
Usar texto visible puede ser adecuado cuando ese texto forma parte del comportamiento esperado. Por ejemplo, un mensaje de error, una confirmación o una etiqueta importante.
Pero puede ser frágil cuando el texto cambia con frecuencia por decisiones de diseño, marketing, traducción o ajustes de tono.
| Uso del texto | Recomendación |
|---|---|
| Mensaje de confirmación funcional. | Puede ser una verificación válida. |
| Texto decorativo o promocional. | No conviene depender de él. |
| Etiqueta estable de un campo. | Puede ser útil si forma parte del contrato de la UI. |
| Texto sujeto a traducción frecuente. | Conviene usar otro identificador o controlar el idioma del ambiente. |
Muchas interfaces muestran listas dinámicas: productos, órdenes, turnos, usuarios o solicitudes. En estos casos, la prueba debe identificar el elemento correcto sin depender de su posición.
Buenas prácticas:
Cuando la prueba crea un dato único, luego puede buscarlo de manera más confiable.
A veces un mismo elemento aparece varias veces en una pantalla. Por ejemplo, varios botones "Editar" en una tabla. En esos casos, no alcanza con seleccionar "Editar"; necesitamos ubicar el botón dentro del contexto correcto.
Ejemplo conceptual:
El contexto evita que la prueba interactúe con el elemento equivocado.
Un selector puede encontrar un elemento que existe en el HTML, pero que no está listo para usarse. Puede estar oculto, deshabilitado, cubierto por otro elemento o duplicado en una versión móvil y otra de escritorio.
Antes de interactuar, conviene verificar:
Esto conecta el tema de selectores con el tema anterior de sincronización.
Los identificadores de prueba son más mantenibles cuando se alinean con el lenguaje del producto. Si el negocio habla de "solicitudes", "turnos", "órdenes" o "cursos", esos términos deberían aparecer en los nombres cuando corresponda.
Ejemplos:
course-buy-buttonappointment-confirm-buttonrequest-status-labelorder-history-tablepayment-rejected-messageEsto ayuda a que los escenarios sean comprensibles para el equipo y no dependan de nombres técnicos internos.
Los selectores confiables no son solo responsabilidad de QA. El equipo de desarrollo puede ayudar agregando identificadores estables y evitando cambios innecesarios en elementos que son parte de pruebas críticas.
Buenas prácticas de equipo:
Cuando el equipo diseña la aplicación pensando en testabilidad, las pruebas E2E se vuelven más simples y estables.
Para un flujo de compra de curso, podríamos necesitar elementos como estos:
| Elemento | Identificador posible | Uso en la prueba |
|---|---|---|
| Botón para comprar curso | course-buy-button |
Iniciar el flujo de compra. |
| Campo de cupón | checkout-coupon-input |
Ingresar una variante alternativa del flujo. |
| Botón confirmar pago | checkout-confirm-payment |
Ejecutar la acción principal. |
| Mensaje de compra confirmada | purchase-success-message |
Verificar la confirmación visible. |
| Curso en "Mis cursos" | my-courses-course-item |
Comprobar que el curso quedó habilitado. |
Al trabajar con selectores en pruebas E2E, conviene evitar estos errores:
button, item o section.Antes de usar un selector en una prueba E2E, podemos revisar:
Los selectores son una parte técnica pequeña, pero tienen un impacto grande en la estabilidad de las pruebas End-to-End. Una suite puede volverse frágil si depende de detalles visuales que cambian con frecuencia.
Elegir identificadores estables, significativos y alineados con el flujo permite que las pruebas fallen por problemas reales y no por cambios accidentales de la interfaz.
En el próximo tema veremos verificaciones: qué comprobar al final y durante el flujo.