Contenido del curso
Estructura de un test
Reto #1
Debug de un test
Reto #2
Recomendaciones finales
Recomendaciones finales para tests con Playwright
Resumen
Si llegaste hasta acá con Playwright, lo siguiente es entender cómo aprovechar al máximo esta herramienta de testing end-to-end. Estas recomendaciones finales te ayudan a escribir pruebas más efectivas, evitar errores comunes y conectarte con la comunidad open source que mantiene viva la herramienta.
¿Por qué los selectores definen la calidad de tus tests en Playwright?
Los selectores son el corazón de cualquier test automatizado. La elección que hagas entre un selector u otro marca la diferencia entre una suite de pruebas confiable y una que se rompe cada vez que el equipo de desarrollo toca el HTML.
Piénsalo así: si eliges un selector frágil, tu test va a fallar por razones que no tienen que ver con bugs reales. Y ahí pierdes tiempo reparando tests en lugar de encontrar problemas reales en la aplicación.
¿Qué selector debo usar en Playwright? Prefiere selectores semánticos como roles, labels o test-ids sobre selectores basados en clases CSS o estructura del DOM, porque son más estables ante cambios de diseño.
¿Se pueden automatizar captchas con Playwright?
No, y tampoco deberías intentarlo. Los captchas existen precisamente para verificar que una persona humana esté usando la aplicación, así que automatizarlos rompe el propósito del control de seguridad.
La recomendación práctica es trabajar con un ambiente de pruebas donde el equipo de desarrollo desactive el captcha. Así puedes correr tus pruebas end-to-end sin pelearte con un sistema que no fue diseñado para ser automatizado.
¿Playwright sirve para saltarse captchas? No. Playwright automatiza interacciones de usuario, no está hecho para evadir sistemas anti bot. Configura un entorno de testing sin captcha en su lugar.
¿Cómo aprovechar mejor Playwright en el día a día?
Gran parte de tu tiempo como persona que escribe tests no se va en crear pruebas nuevas, sino en leer las de otros, repararlas y mejorarlas. Por eso las herramientas de debugging que ofrece Playwright son tus mejores aliadas.
Documentación oficial siempre a la mano
La documentación de Playwright se actualiza constantemente, versión a versión y semana a semana. Si revisas el repositorio, vas a notar cómo el equipo mantiene los contenidos al día con cada cambio del proyecto.
Usarla como referencia primaria te ahorra horas de prueba y error. Está bien escrita y cubre desde lo básico hasta casos avanzados.
La comunidad open source detrás de Playwright
Playwright tiene apenas tres años de existencia, lo que significa que estás entrando temprano a un proyecto en plena expansión. Apoyarte en la comunidad multiplica tu aprendizaje.
Algunos datos que muestran qué tan activa está la comunidad:
- Alrededor de 700 issues abiertos pendientes por resolver en GitHub.
- Más de 7000 issues ya cerrados, es decir, peticiones y preguntas resueltas.
- Es un proyecto open source, así que puedes contribuir directamente.
- Existe una comunidad activa de estudiantes en Platzi aprendiendo en paralelo.
Esa relación entre issues abiertos y cerrados habla de un equipo atento a lo que reporta la gente que usa la herramienta.
¿Por dónde empezar a escribir tests si una app no tiene ninguno?
Los tests end-to-end son un excelente punto de partida cuando heredas una aplicación sin cobertura. La razón es simple: validan que el usuario pueda completar las acciones principales que la app promete.
No necesitas ser experto para empezar. Cualquier persona puede escribir tests, y cada prueba que sumas reduce el riesgo de que algo se rompa en producción sin que nadie se entere.
Si te gustó el camino hasta acá, consigue tu certificado y compártelo etiquetando a @lukamay_ en Twitter contando qué aprendiste. Nos leemos en los comentarios para seguir hablando de testing.