Description
Los tests end-to-end fallan de dos formas. No existen, así que un checkout roto sale a producción porque todos los tests unitarios pasaron aislados. O existen y son inestables, fallando al azar por timing y selectores hasta que el equipo deja de confiar en ellos y hace merge con el build en rojo, lo que es peor que no tener tests. La mayoría de las suites de Playwright se mueren de inestabilidad, y casi toda esa inestabilidad es autoinfligida: esperas arbitrarias, selectores frágiles atados al DOM, tests que dependen entre sí y de los datos de ayer, y sin aislamiento. Escribir tests E2E que cazan bugs reales y se mantienen confiables es una habilidad de verdad, y se trata sobre todo de esperar lo correcto, seleccionar lo estable, y mantener cada test independiente.
Este libro te enseña a construir una suite de Playwright que caza bugs reales y se mantiene confiable, en vez de una pila inestable que el equipo aprende a ignorar. Arranca desde por qué importa el testing end-to-end y dónde encaja (los pocos flujos de alto valor que vale la pena testear a través de todo el stack, frente a las cosas que un test unitario debería cubrir) para que no te ahogues en tests lentos. Después va a fondo en las dos cosas que deciden si una suite es confiable: localizar elementos por lo que el usuario ve y por roles y test ids estables en vez de rutas CSS frágiles, y el auto-waiting de Playwright para que dejes de salpicar esperas arbitrarias que son la causa número uno de inestabilidad. Construye el oficio de verdad: escribir un test que refleja un recorrido del usuario, el patrón page object para que un cambio de UI actualice un archivo en vez de cincuenta, manejar la autenticación y los datos de prueba para que los tests arranquen desde un estado conocido y no dependan entre sí, y mockear la red para testear el frontend sin un backend inestable. Los capítulos de confiabilidad son el corazón del libro: cazar la inestabilidad en su origen, aislar los tests para que corran en cualquier orden y en paralelo, y depurar una falla con traces, videos y capturas en vez de adivinar. Cierra con correr la suite en CI para que de verdad controle los releases, mantenerla lo bastante rápida como para que la gente la espere, y saber qué no testear de punta a punta. Los ejemplos son una app real, mostrada con un test inestable y después uno sólido. Para ingenieros que quieren tests E2E en los que la gente confíe lo suficiente como para bloquear un release.
¿Este libro es para vos?
Este libro es para: ingenieros que necesitan testear una app web real de punta a punta y quieren una suite de Playwright que caza bugs de verdad y se mantiene en verde por las razones correctas, no una pila inestable que todos aprenden a ignorar.
Todos los capítulos, uno por uno
- Capítulo 1: La build roja que el equipo aprendió a ignorar
- Capítulo 2: ¿Qué flujos valen tu test más lento?
- Capítulo 3: Por qué un rediseño pone cuarenta tests en rojo
- Capítulo 4: La apuesta que perdés cada vez que adivinás una espera
- Capítulo 5: El test que pasa aunque el checkout esté roto
- Capítulo 6: Un botón reetiquetado, cuarenta y tres tests rotos
- Capítulo 7: El test que falla por datos que nunca fueron suyos
- Capítulo 8: ¿Cómo hacés que un backend sano falle a pedido?
- Capítulo 9: Cuando el rojo deja de significar algo
- Capítulo 10: Los dos tests que pasan solos y fallan juntos
- Capítulo 11: Dejá de mandar console.log a un CI que no podés ver
- Capítulo 12: El test que solo corría en laptops cerradas
- Capítulo 13: La build en la que tu equipo por fin cree
