No tienes acceso a esta clase

隆Contin煤a aprendiendo! 脷nete y comienza a potenciar tu carrera

Aprende todo un fin de semana sin pagar una suscripci贸n 馃敟

Aprende todo un fin de semana sin pagar una suscripci贸n 馃敟

Reg铆strate

Comienza en:

3D
6H
20M
8S

Assertions

7/17
Recursos

Aportes 4

Preguntas 1

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad?

o inicia sesi贸n.

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

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 鈥渉ardcore鈥.
    .

馃搶 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.