Curso de Automatización de Test con Playwright
Curso de Automatización de Test con Playwright

Fundamentos

1

Hola mundo con Playwright

2

Instalación de Playwright

3

Cualquiera puede escribir tests

4

Ejecuta tus tests

Estructura de un test

5

Selectores

6

Más sobre selectores

7

Assertions

Reto #1

8

Información importante para resolver el reto

9

Reto: escribe un test sin el uso de codegen

Debug de un test

10

Playwright inspector

11

Debugging selectors

12

Debugging con API logs

13

Playwright Tracing

Reto #2

14

Reparar un test que no funciona

15

Leyendo errores de ejecución de un test

16

Resolviendo errores con la ayuda del inspector

Recomendaciones finales

17

Recomendaciones para mejorar tus test

No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Si ya tienes una cuenta,

Curso de Automatización de Test con Playwright

Curso de Automatización de Test con Playwright

Lupe Canaviri Maydana

Lupe Canaviri Maydana

Assertions

7/17
Recursos

¿Qué son las assertions y por qué son importantes en los tests?

Las assertions son fundamentales para verificar el comportamiento esperado de una aplicación. Actúan como el componente que certifica que un test produce los resultados deseados. Son declaraciones en el código que aseguran que el resultado final del test coincida con lo esperado, lo cual es crucial para la confiabilidad y funcionalidad en el desarrollo ágil.

En esencia, si una assertion falla, significa que el comportamiento de la aplicación no está alineado con las expectativas definidas, indicando posibles errores o reconsideraciones en el desarrollo.

¿Cómo configurar un test básico utilizando assertions?

Para empezar con un test básico en Visual Studio Code, sigue estos pasos:

  1. Crea un nuevo test file: Denomina el archivo assert.spec.ts y toma como base algún código anterior de UI Testing.
  2. Define el objetivo del test: En este caso, probamos la funcionalidad del input en la URL uitestingplayground.com/textinput.
  3. Escenario del test:
    • Abre la URL y carga la página.
    • Selecciona el input y asegúrate que esté visible.
    • Llena el input con un texto de tu elección.
    • Haz clic en el botón y verifica que el texto del botón haya cambiado.

El código para iniciar esto se vería de la siguiente manera:

test('playing with sessions', async ({ page }) => {
  await page.goto('https://uitestingplayground.com/textinput');
  const input = await page.locator('#newButtonName');
  await expect(input).toBeVisible();
  await input.fill('yout');
  const button = await page.locator('#updatingButton');
  await button.click();
  await expect(button).toContainText('yout');
});

¿Cómo asegurarte de que un elemento esté visible antes de interactuar con él?

Verificar si un elemento es visible antes de interactuar con él es clave para evitar errores en los tests. Utilizando la función expect junto con .toBeVisible(), corroboras la visibilidad del elemento:

await expect(page.locator('#newButtonName')).toBeVisible();

Esto determina que el test sólo continúa si el elemento #newButtonName, en este caso un input, es visible en la página.

¿Qué pasos seguir para llenar un input y verificar un cambio en el botón?

El siguiente paso consiste en llenar un input y comprobar si un botón refleja este cambio. Para hacerlo:

  1. Rellena el input:

    • Usa el localizador del input y refiérete al ID con fill() usando el texto deseado:
    await page.locator('#newButtonName').fill('yout');

  2. Haz clic y verifica el botón:

    • Localiza el botón por su ID y ejecuta click(). Luego verifica que el texto del botón haya cambiado usando toContainText():
    await page.locator('#updatingButton').click();
await expect(page.locator('#updatingButton')).toContainText('yout');

¿Qué otras opciones de validación existen?

Las assertions ofrecen múltiples posibilidades. Puedes, por ejemplo:

  • Verificar si un elemento es visible o no.
  • Confirmar que un elemento contiene un cierto texto.
  • Utilizar conditions negativas para asegurarte que un estado no se cumple.
  • Comparar con snapshots existentes para comprobar que el estado visual o funcional es consistente con versiones anteriores.

Explora la documentación de Playwright para conocer más funciones y ejemplos específicos. Además, si ya tienes experiencia con Jest, algunas características son transferibles, facilitando aún más el uso de assertions en tus test.

Aportes 4

Preguntas 1

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Douglas Lovera

Douglas Lovera

hace 2 años

Gracias a copilot me di cuenta que también se puede usar el método isVisible() para saber si el elemento es visible sin usar expect:

await page.locator('input#newButtonName').isVisible();
Irving Juárez

Irving Juárez

hace 2 años

Veo dos cosas como se puede simplificar un poco el codigo.
.
Podemos poner en variables cosas como el texto que se va a escribir en el input, para ya no tener que escribirlo dos veces

const content = "Jude"
await expect(locator).fill(content)
...
await expect(locator).toContainText(content)

.
Ademas de eso, estamos escribiendo varias veces el buton o el input con el page.locator("cssLocator"). Sin embargo, podemos hacer esto solo una vez de la siguiente manera

const btn = page.locator("#updatingButton")
await btn.click()
await expect(btn).toHaveText(textContent)

Toma en cuenta que la variable btn no necesita un await antes
.
Finalmente, hay una manera de escribir en el input el texto que queremos:

await page.type("cssSelector", textContent)

Esto es porque Playwright tiene una API muy similar a la de Puppeteer

Emmanuel Rodríguez

Emmanuel Rodríguez

hace 2 años

Recomendaciones de pruebas Frontend

El desarrollo de pruebas, en una mal ejecución, terminará siendo un lastre que impedirá tanto al desarrollador como al producto, sincronizarse rápida con su público o audiencia de uso.
.
Para el caso de pruebas en Frontend, existen recomendaciones que permiten buscar funcionalidades (TDD) o comportamiento (BDD), que para fines de la necesidad resultará en el valor que aportará en el mercado.
.

Separa la interfaz de usuario de la funcionalidad

  • En desarrollo, al planificar la arquitectura de aplicaciones Frontend, la mayoría recae en la generación de componentes e interfaces visuales.
    .
  • Un desarrollo, se deberá pensar en su desacoplamiento de elementos interaccionables con el usuario y su disposición en una página web.
    .
  • Metodologías como BEM o Atomic Design, permiten su distribución de dichas entidades. Sin embargo, queda en incógnita la arquitectura general de la aplicación.Por ejemplo, el uso de librerías como ReactJS, prefieren dejar una abstracción de Hooks o contextos como una subcarpeta más que una arquitectura de controladores y servicios.

.

Consultar elementos HTML basados en atributos que es poco probable que cambien

  • En desarrollo, un componente poseerá un estructura con entradas y salidas que permitirán abstraer su compleja funcionalidad para después manipular su comportamiento, modularmente.
    .

ℹ️ Definición
Un componente es una entidad que interacciona con un usuario; también posee complejidad dependiente de entradas variables. Su diseño deberá ser autónoma para controlar información, errores y ambigüedad .

.

  • En diseño, el desarrollador deberá identificar y estructurar la jerarquía de atributos esenciales de sus componentes para que, en pruebas, pueda evaluar escenarios primarios (requerimientos de usuario) y secundarios (como los consecuentes o dependientes).
    .

Si es posible, desarrolla interfaces y componentes con información real

  • Si bien, los wireframes y diseños finales suelen no entregarse con información y escenarios reales, el desarrollo no será la excepción.
    .
  • En desarrollo, un componente debe ser diseñado pensando en sus casos límite, los cuales definen aquellos excesos de algo. Por ejemplo, un texto muy largo, información sin formato, calidad de imágenes, etc.
    .
  • A veces, nuestras APIs suelen no comunicarse con los desarrolladores dejando que los Frontend se las arreglen como puedan. Mockear la información es útil cuando conoces su estructura, cuando no, se interpreta, dejando la información en ambigüedad impidiendo su estabilidad al final de entrega.
    .
  • En dichos escenarios, desarrollar pruebas antes que el componente en sí permitirá reducir dichos casos de caos. Recuerda que los componentes, a veces, requieren de un paso preliminar de retroalimentación de la API, por lo que al estructurar flujos con base en datos reales, permitirán reducir “hardcore”.
    .

📌 Referencias
Para más recomendaciones con código real, puedes consultarlo en 50 Best Practices

.

Por el placeholder no se puede, tiene que ser por el name o el id del campo.