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();
Fundamentos
Hola mundo con Playwright
Instalación de Playwright
Cualquiera puede escribir tests
Ejecuta tus tests
Estructura de un test
Selectores
Más sobre selectores
Assertions
Reto #1
Información importante para resolver el reto
Reto: escribe un test sin el uso de codegen
Debug de un test
Playwright inspector
Debugging selectors
Debugging con API logs
Playwright Tracing
Reto #2
Reparar un test que no funciona
Leyendo errores de ejecución de un test
Resolviendo errores con la ayuda del inspector
Recomendaciones finales
Recomendaciones para mejorar tus test
No tienes acceso a esta clase
¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera
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.
Para empezar con un test básico en Visual Studio Code, sigue estos pasos:
assert.spec.ts
y toma como base algún código anterior de UI Testing.uitestingplayground.com/textinput
.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');
});
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.
El siguiente paso consiste en llenar un input y comprobar si un botón refleja este cambio. Para hacerlo:
Rellena el input:
fill()
usando el texto deseado:await page.locator('#newButtonName').fill('yout');
Haz clic y verifica el botón:
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');
Las assertions ofrecen múltiples posibilidades. Puedes, por ejemplo:
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
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();
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
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.
.
.
ℹ️ 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 .
.
📌 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.
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?