Repara 3 tests rotos en Playwright

Si llegaste hasta aquí con ganas de medir lo aprendido, este reto final de Playwright es tu momento. Vas a trabajar como si te hubieras unido al equipo que mantiene la documentación de Playwright, con la misión de reparar tres tests rotos en el archivo search.spec.ts. Es práctico, retador y replica el flujo real de un QA Automation.

¿En qué consiste el reto final de Playwright?

La idea es sencilla en su planteamiento, pero exigente en su ejecución. Vas a recibir un repositorio en GitHub con un conjunto de pruebas automatizadas que actualmente están fallando, y tu trabajo es dejarlas en verde.

El contexto es divertido: imagina que entraste al equipo de Playwright y te toca testear sus propios docs. Los tests viven en el folder test, dentro del archivo search.spec.ts, y son tres casos que debes diagnosticar y reparar uno por uno.

¿Qué es search.spec.ts? Es el archivo donde están escritos los tres tests automatizados que validan la búsqueda en la documentación de Playwright. Ahí harás todos los cambios.

¿Cómo clonar el repositorio y correr las pruebas?

El flujo de trabajo sigue las buenas prácticas de cualquier proyecto open source. En el repositorio que está en la zona de recursos vas a encontrar las instrucciones de instalación y de ejecución, pero el camino general es este:

• Hacer fork del repositorio hacia tu cuenta de GitHub.
• Clonar tu fork a tu máquina local.
• Instalar las dependencias siguiendo el README.
• Correr las pruebas para confirmar que las tres están en rojo.
• Reparar cada test hasta verlos pasar con el famoso chulito verde.

Una vez que todo esté funcionando, envías tu solución creando un pull request hacia el repositorio original. Ese PR es tu entrega.

¿Qué es un pull request? Es una solicitud para integrar tus cambios al repositorio original. Permite que el mantenedor revise tu código antes de fusionarlo.

¿Qué hacer si te atoras resolviendo los tests?

Atorarse es parte del proceso, no una señal de que vas mal. Cuando sientas que un test no cede, tienes varias rutas para destrabarte sin perder el ritmo.

• Vuelve a las clases anteriores y revisa los conceptos que ya practicaste.
• Consulta la documentación oficial de Playwright para validar selectores y APIs.
• Apóyate en la comunidad de Platzi para contrastar ideas.
• Relee los tests que tú mismo escribiste antes; ahí suele estar la pista.

La habilidad que estás entrenando aquí no es solo escribir código, es depurar pruebas automatizadas y leer mensajes de error con criterio.

¿Y si es tu primera vez clonando un repositorio en GitHub?

No te preocupes, también está cubierto. En la zona de recursos hay un enlace al curso de GitHub para que entiendas el flujo de fork, clone, commit y pull request sin fricción.

Dominar este flujo te sirve mucho más allá del reto: es la base de cualquier colaboración profesional en proyectos de software, y especialmente útil cuando trabajas en equipos de QA distribuidos.

Ahora sí, abre tu terminal, haz el fork y empieza a depurar. ¿Qué test crees que vas a reparar primero? Cuéntamelo en los comentarios.