Flujo de compra completo con Playwright

Automatizar un flujo de compra con Playwright te enseña a combinar selectores, assertions y acciones del usuario en un solo spec. Aquí resolvemos un reto real: añadir un producto al carrito en una tienda online, verificar el modal de éxito y continuar comprando, todo en un test end to end.

Este ejercicio es ideal si ya creaste tus primeros tests y quieres practicar con un caso de uso completo que mezcla hover, clics múltiples, dropdowns y validaciones visuales.

Cómo planeas un test antes de escribir código

Antes de tocar el editor, conviene traducir el flujo en pseudocódigo. Así tu cerebro mapea cada acción a un locator o a un assertion sin perderse en sintaxis.

Los pasos del reto, tomados directo de la tienda en automationpractice.com/index.php, son:

• Ir a la URL de la tienda online.
• Hacer hover sobre el primer producto del listado.
• Clic en More para ver detalles del primer producto.
• Clic dos veces en el botón Más para llegar a tres unidades.
• Seleccionar un nuevo tamaño en el menú dropdown.
• Clic en Add to cart.
• Verificar que el modal con el texto de éxito sea visible.
• Clic en Continue Shopping.
• Verificar que el modal ya no esté visible.

Escribe estos pasos como comentarios dentro de tu archivo tienda_online.spec.ts. Vas a convertir cada línea en código Playwright [02:45].

¿Por qué escribir pseudocódigo antes del test? Porque te obliga a pensar el caso de uso como usuario, no como programador. Cada comentario se vuelve una línea de código con un locator y una acción clara.

Qué selectores usar cuando hay elementos repetidos

La tienda muestra varios productos con el mismo texto More, y ahí aparece el primer reto técnico. Si usas solo hasText: 'More', Playwright lanza un error porque encuentra siete coincidencias [09:30].

La solución es combinar el ID del contenedor #homefeatured con la etiqueta a y filtrar por el primero usando nth=0. Ese patrón te sirve siempre que un selector devuelva múltiples elementos y necesites uno específico.

Para el botón de cantidad, inspeccionas y ves que la clase .button-plus aparece una sola vez en la página. Lo confirmas con document.querySelectorAll('.button-plus') en la consola del navegador. Cuando un selector es único, puedes usarlo sin sufijos.

El menú de tallas usa el ID #group_1, que también es único porque los IDs no se repiten en HTML válido. Para seleccionar la opción L escribes selectOption('2') con el valor entre comillas, no como número [12:50].

Cómo validar selectores desde la consola del navegador

Un truco que ahorra tiempo: usa document.querySelector y document.querySelectorAll en las DevTools antes de pegar el selector en tu test. Si querySelectorAll devuelve un solo elemento, tu locator es seguro. Si devuelve varios, necesitas un filtro adicional.

Esta validación previa evita errores como strict mode violation en Playwright, que ocurre cuando un locator matchea más de un elemento.

Cómo escribir assertions para modales y elementos invisibles

Después de hacer clic en Add to cart, esperas que aparezca un div con ID #layer_cart que contiene el mensaje de éxito. Aquí encadenas dos assertions:

• toBeVisible() para confirmar que el modal apareció.
• toContainText('Product successfully added to your shopping cart') para validar el mensaje exacto.

La parte interesante viene al final. Cuando el usuario hace clic en Continue Shopping, el modal debe desaparecer. Para negar una condición usas .not.toBeVisible(), que invierte el assertion original [16:20].

¿Cómo verifico que un elemento desapareció en Playwright? Usa expect(locator).not.toBeVisible(). El .not invierte cualquier assertion y es la forma estándar de validar que algo dejó de mostrarse en pantalla.

Para el botón Continue Shopping, la clase .button-container solo aparece una vez, pero contiene tres span. Combinas .button-container span con nth=0 para apuntar al primero.

Cómo depurar cuando el test falla

La primera ejecución casi nunca pasa, y eso es parte del proceso. En este reto aparecieron dos errores típicos:

• Selector ambiguo: el texto More se repetía en siete elementos. Se resolvió con nth=0.
• Tipo de dato incorrecto: selectOption(2) falló porque esperaba un string o un objeto. Se corrigió con selectOption('2').

Usar el modo headed con slowMo te deja ver cada paso en el navegador, lo cual es oro cuando estás depurando. Cuando el test ya funciona, comentas o quitas slowMo para que corra rápido. La diferencia es notable: el mismo test pasó de varios segundos visibles a unos siete segundos en modo headless [19:40].

Qué revisar en el reporte cuando el test pasa

El reporte HTML de Playwright te muestra cada paso con su tiempo de ejecución. Si un locator tarda demasiado, puedes optimizarlo o ajustar el timeout. Si todo pasa en verde, tu flujo está sólido y puedes compararlo con lo que generaría Codegen para ver alternativas de sintaxis.

¿Qué selector te ha dado más problemas en tus tests? Cuéntalo en los comentarios y comparte cómo lo resolviste.