Ganancias:
- Capacidad para producir un código de prueba de interfaz de usuario sólido con inteligencia artificial, que incluye data-testid, espera abierta y afirmación que verifica el resultado real del usuario.
- Capacidad para evitar pruebas frágiles (selector incorrecto, espera ciega) y hacer que las pruebas sean fáciles de mantener en la estructura del modelo de objetos de página.
- Capacidad para probar cada prueba de UI producida al descifrar el código y detectar y corregir pruebas aprobadas falsamente
Cada clic, cada llenado de formulario, cada transición de página que realiza un usuario en un navegador no se puede probar una y otra vez a mano; es por eso que existe la automatización de pruebas de UI (interfaz de usuario; estas pruebas imitan el comportamiento del usuario al manejar mediante programación un navegador real). Selenium, Playwright y Cypress son las herramientas más comunes para este trabajo. La inteligencia artificial (IA) está altamente capacitada para escribir el código de estas herramientas: usted describe un caso de prueba, la IA le brinda un borrador de un script de automatización viable. Pero aquí vuelve a entrar en juego la advertencia central de este módulo: el código de prueba de UI que produce la IA a menudo puede ser pruebas frágiles que “se iluminan en verde pero verifican algo incorrecto” o ondean con el viento. Su trabajo no es ejecutar este código, sino asegurarse de que realmente verifique de manera sólida lo correcto.
En esta unidad, nuestro objetivo es producir pruebas de IU sólidas, mantenibles y verdaderamente validadoras con IA; Aprenderás a evitar pruebas frágiles.
Los tres pilares de las pruebas sólidas de UI
1. Localizador de elementos correcto. Una prueba utiliza un selector para encontrar el elemento en la página. La IA a menudo produce selectores frágiles: rutas XPath largas (la dirección depende demasiado de la estructura de la página), selectores basados en nombres de clases CSS (se rompen cuando cambia el diseño). La forma robusta son los atributos estables como data-testid que el desarrollador agregó para realizar pruebas. Impone esto explícitamente a la IA.
2. Espera explícita. La principal fuente de vulnerabilidad en las pruebas de IU es el tiempo. El sueño constante(3) (espera ciega) es una mala práctica: a veces no es suficiente, a veces es una pérdida de tiempo. La forma correcta es utilizar una espera explícita, que dice "esperar hasta que aparezca este elemento". El dramaturgo hace esto en gran medida de forma automática; En Selenium debes solicitarlo explícitamente.
3. Afirmación significativa. La prueba debe verificar el resultado que el usuario realmente verá, como "el número de pedido apareció en la pantalla", no solo "página cargada". Si la prueba producida por la IA no tiene afirmación o no es importante, esa prueba produce un pseudo-aprobado (1ª unidad).
Precaución: Cuando vea por primera vez una prueba de IU generada por IA, verifique tres cosas como máximo: ¿están los selectores comprometidos (data-testid), están en espera (sin suspensión ciega) y la afirmación verifica el resultado real del usuario? Si estos tres están bien, la prueba probablemente sea sólida.
Modelo de objetos de página
A medida que las pruebas crecen, escribir selectores dentro de cada prueba se convierte en una pesadilla de mantenimiento. El modelo de objetos de página (POM: patrón de diseño que recopila selectores y acciones para cada página/pantalla en una sola clase) mantiene el selector en un solo lugar; Cuando la interfaz cambia, la actualiza en un solo archivo. Hacer que la IA produzca las pruebas en una estructura POM, en lugar de hacerlo directamente; Esto hace que el mantenimiento sea radicalmente más fácil.
Aviso débil / Aviso fuerte
Débil: "Escribe una prueba de Selenium para la página de inicio de sesión".
Fuerte: "Escriba una prueba de flujo de inicio de sesión con Playwright (TypeScript). Los selectores solo usan data-testid; no controlan lo que ve el usuario, ni el título de la página".
Aviso potente; La herramienta proporciona el lenguaje, la política de selección, la estrategia de espera, la arquitectura (POM) y la expectativa de afirmación expresiva.
Datos de prueba e independencia del entorno.
Una prueba de UI sólida no solo se escribe correctamente, sino que también crea y limpia sus propios datos de prueba. Las pruebas generadas por IA a menudo se vinculan a un usuario o registro que se supone que ya existe en el entorno (“inicie sesión como usuario administrador”). Esta suposición se rompe cuando la prueba se ejecuta en otro entorno o después de otra prueba (problema de dependencia de orden en la unidad 9). La verdad es que cada prueba crea los datos que necesita al comienzo de la prueba (o los prepara con una llamada API) y los limpia al final. Indique explícitamente a la IA que "configure cualquier dato de los que dependa esta prueba dentro de la prueba; no asuma datos ya preparados desde el exterior".
Otro punto crítico es no realizar pruebas de UI con datos reales del usuario. Si se utiliza una copia de la base de datos de producción en el entorno de prueba, estos registros son datos de personas reales; Las capturas de pantalla y las grabaciones de prueba pueden revelar estos datos. Utilice relatos de prueba sintéticos (ficticios); protege la confidencialidad y hace que las pruebas sean reproducibles. Realizar una prueba de "cancelación de pedido" con una cuenta de cliente real es un error tanto ético como operativo.
Consejo: Mantenga la menor cantidad posible de pruebas de IU; Deje la verificación real a la API y las pruebas unitarias, que son rápidas y estables. Las pruebas de UI son costosas y frágiles; úselas solo para validar un flujo de usuarios verdaderamente de un extremo a otro (lógica piramidal de prueba).
Comparación de vehículos
característica
selenio
dramaturgo
ciprés
idiomas
Java, C#, Python, JS
JS/TS, Python, .NET, Java
JavaScript/Mecanografiado
modo de espera automático
No (a mano)
Sí (fuerte)
si
Navegador múltiple
ancho
Cromo/Firefox/WebKit
Cromo dominante
tendencia a la fragilidad
Alto (espera manual)
bajo
bajo
Facilidad de aprendizaje
medio
fácil
fácil
operación paralela
Se requiere cuadrícula
incorporado
Residente/pagado
Al solicitar un código a AI, indique claramente a qué vehículo pertenece; De lo contrario, puede generar código confuso y que no funcione.
Cuatro plantillas copiables
1) Generación de pruebas de UI sólidas:
Su rol: ingeniero senior de automatización de pruebas. Escriba pruebas con [herramienta + lenguaje] para el siguiente flujo: [flujo]. Reglas: - Selectores data-testid solamente; Usando clase XPath/CSS. - No dormir a ciegas; Utilice espera explícita/automática. - Aplicar modelo de objetos de página. - Deje que cada afirmación verifique el resultado real del usuario. Comenta al inicio de cada prueba qué criterios de aceptación estás validando.
2) Control de fragilidad:
Examine la siguiente prueba de IU para detectar fragilidad: - ¿Hay un selector inestable (largo?
3) Conversión a objeto de página:
Convierta el siguiente código de prueba simple en una estructura de modelo de objetos de página. Mover selectores y acciones a clases de páginas; Deje que el archivo de prueba lea solo el flujo del escenario. [Herramienta/idioma]. Código: [pegar código]
4) Prueba de pseudotransición:
Demuestre que esta prueba de IU realmente valida: ¿Qué cambio único hago en el código de la aplicación que hará que esta prueba se vuelva ROJA? Si no puede encontrar un cambio que rompa la prueba, la prueba es inadecuada; agregar afirmaciones faltantes. Prueba: [pegar prueba]
tres mini casos
Caso 1: Liberación del selector frágil. De las 40 pruebas que un equipo produjo con IA, el 70% no funcionaron después de una actualización de la interfaz; Ninguno de ellos eran errores reales, todos eran selectores XPath frágiles. El equipo convirtió las pruebas en una base de datos de prueba con la plantilla de "verificación de fragilidad". Durante las siguientes tres actualizaciones de la interfaz, el número de rupturas falsas se redujo a cero; El tiempo de mantenimiento disminuyó de 6 horas a 30 minutos por semana.
Caso 2: prueba de IU falsa. AI produjo una prueba de "agregar al carrito"; la prueba fue verde. Cuando se ejecutó la plantilla de "prueba de paso falsa", la prueba pareció verificar solo el clic en el botón y el título de la página, sin verificar nunca si el contador del carrito había aumentado o no. Incluso si la lógica del carrito se rompió por completo, la prueba pasó. Se agregó aserción verdadera (la insignia del carrito es "1").
Caso 3: Trampa de espera ciega. En la prueba de Selenio producida por IA, hubo sueño(2) después de cada paso; 60 pruebas tomaron 14 minutos y aun así se rompieron ocasionalmente. Después de cambiar a espera abierta (esperar a que se pueda hacer clic en el elemento), el tiempo se redujo a 5 minutos y la fragilidad desapareció. La espera ciega era lenta y poco fiable.
Errores comunes
- Aceptando selectores frágiles. Utilizando los XPath largos generados por la IA tal cual; Las pruebas fallan en el primer cambio de interfaz.
- Dejando el "sueño" ciego. "Resolver" el tiempo con una espera fija; a la vez lento e indeciso.
- Afirmación trivial. Simplemente verifique que la página se haya cargado; no verificar el resultado real del usuario (pase falso).
- Crecer sin POM. Distribuir selectores a cada prueba; Actualizar manualmente docenas de archivos cuando cambia la interfaz.
- Sin especificar la herramienta. No decirle a la IA qué herramienta/lenguaje desea; obteniendo código desordenado y que no funciona.
- Confiando cuando ejecutas el código generado y pasas. No realizar pruebas descifrando el código.
En resumen
La automatización de las pruebas de UI verifica el comportamiento del usuario manejando el navegador real con el programa. La IA genera este código rápidamente, pero existen dos grandes obstáculos: pruebas frágiles (selector incorrecto, espera ciega) y pruebas de aprobación falsa (afirmación incompleta/trivial). Los tres pilares de las pruebas sólidas de UI son el selector de confirmación (data-testid), la espera explícita y la afirmación que verifica el resultado real del usuario. Tener pruebas generadas en el modelo de objetos de página simplifica radicalmente el mantenimiento. Pruebe cada prueba generada con la pregunta "¿qué cambio romperá esto?"
Tarea de aplicación
Seleccione un flujo de usuario de su propio proyecto (por ejemplo, iniciar sesión o buscar). Haga que la IA escriba pruebas con la plantilla de “generación robusta de pruebas de IU”. Luego: (1) verifique y arregle los selectores y espera con una "verificación de fragilidad", (2) demuestre que cada prueba realmente se valida con una "prueba de pseudo-paso", (3) rompa el código y observe que la prueba se vuelve roja. Informe la cantidad de pruebas producidas y corregidas, y la cantidad de vulnerabilidades y pseudopasos que encontró.
lista de verificación
- [] Le di a la IA la herramienta, el lenguaje, la política de selección y la arquitectura (POM) claramente.
- [] Verifiqué que los selectores son data-testid.
- [] Me aseguré de usar la espera explícita/automática en lugar del sueño ciego.
- [] Verifiqué que cada afirmación verifica el resultado real del usuario.
- [] Probé cada prueba descifrando el código; Lo vi ponerse rojo.
- [] Recopilé las pruebas en la estructura del modelo de objetos de página.