Assertions

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();

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

.

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

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