Corregir tests que fallan es una de las habilidades más valiosas cuando trabajas con automatización. En esta sesión se aborda un reto práctico donde tres tests de Playwright están rotos y es necesario identificar cada error utilizando herramientas de debugging, el inspector de Playwright y el análisis de reportes. El proceso revela errores comunes como URLs mal escritas, selectores ambiguos y la ausencia de await en aserciones asíncronas.
¿Por qué fallan los tests y cómo leer el reporte de errores?
El punto de partida es un repositorio clonado con tres tests definidos en un archivo spec. Al ejecutar npx playwright test, los tres fallan en apenas nueve segundos. El reporte generado automáticamente lista cada test con su error correspondiente [0:38].
Los tres tests son:
- Realizar una búsqueda que no tenga resultados.
- Limpiar el input de búsqueda.
- Realizar una búsqueda que genere al menos un resultado.
El primer error indica que la dirección URL no pudo resolverse. Esto es una pista clave: el navegador no puede abrir el sitio. Al revisar el archivo de test, la línea cuatro usa page.goto('/'), es decir, solo un slash. La URL completa no aparece ahí porque está configurada como base URL en el archivo de configuración de Playwright [1:28].
¿Qué es la base URL en el archivo de configuración?
Cuando una aplicación siempre comienza con la misma dirección, Playwright permite definir una base URL en el archivo playwright.config. De esta forma, los tests solo necesitan rutas relativas como /. Al inspeccionar la configuración, se descubre un typo: la URL tenía dos letras "e" en lugar de una, convirtiendo playwright.dev en una dirección inexistente [2:05]. Corregir ese pequeño error permite que el navegador abra el sitio correctamente.
¿Qué significa el error de strict mode en selectores?
Tras corregir la URL, los tests siguen fallando, pero ahora en la línea ocho. El reporte toma treinta y ocho segundos y muestra un error diferente: el modo estricto (strict mode) detectó que un selector resuelve a tres elementos en lugar de uno [3:15].
El strict mode está activado por defecto en Playwright para garantizar que cada acción apunte a un único elemento. Un usuario real no puede hacer clic en tres botones simultáneamente, así que el test tampoco debería intentarlo.
Para resolver esto se utiliza el inspector de Playwright ejecutando npx playwright test --debug [4:08]. El inspector muestra visualmente los tres botones encontrados y permite explorar el DOM para obtener un selector más específico. La solución es agregar el atributo name al localizador:
javascript
page.getByRole('button', { name: 'Search' })
Esto reduce la selección a un único botón.
¿Por qué es indispensable usar await en las aserciones?
Con el selector corregido, el test avanza pero falla en la línea catorce. El error indica que un elemento debería ser visible, pero nunca se encuentra dentro del tiempo límite [5:48].
Al abrir el modo debug paso a paso, se observa algo inusual: las líneas catorce y dieciséis se ejecutan al mismo tiempo. Esto ocurre porque les falta la palabra clave await [6:35]. Sin await, las promesas no se resuelven antes de continuar, y Playwright no espera a que la acción anterior termine para verificar la siguiente.
Agregar await antes de cada aserción asíncrona es fundamental:
javascript
await expect(locator).toBeVisible();
await expect(locator).toHaveText('No results for "hasContent"');
¿Cómo detectar diferencias sutiles en el texto esperado?
Incluso con los await corregidos, el test falla una vez más en la línea dieciséis. El reporte muestra en verde el texto esperado y en rojo el texto recibido. La diferencia es muy sutil: el sitio devuelve la palabra hasContent envuelta en comillas, pero el test no las incluía [7:22]. Agregar las comillas dentro del string del test resuelve el problema.
Tras estas correcciones, el primer test pasa exitosamente en cuatro segundos. El reporte confirma que todos los pasos se ejecutaron correctamente en dos punto siete segundos [8:05].
Un truco útil mencionado es usar .only después de test para ejecutar únicamente un test específico dentro de un archivo con múltiples tests, lo que acelera el ciclo de debugging [5:10].
¿Has enfrentado errores similares en tus tests automatizados? Comparte qué herramienta de depuración te ha resultado más útil.
