toHaveAttribute en lugar de toHaveText

Validar el contenido de un input en Playwright requiere una función distinta a la que usarías con texto común. Si vienes intentando usar toHaveText y el test falla, la solución pasa por entender cómo funciona el HTML detrás del campo y cambiar a toHaveAttribute para leer correctamente el atributo value.

¿Por qué falla toHaveText en un input de búsqueda?

Cuando ejecutas el test con npx playwright test, el reporte señala el error en la línea 29: el input no contiene el texto esperado some random text. La pista aparece al inspeccionar el elemento en el navegador [02:15].

Los inputs en HTML no almacenan texto interno como lo haría un <p> o un <div>. Lo que guardan es un atributo llamado value, y ese es el dato que cambia cuando escribes algo en el campo. Por eso toHaveText no encuentra coincidencia: está buscando texto donde no existe.

¿Qué diferencia hay entre text y value en HTML? El texto vive dentro de etiquetas como párrafos o spans. El value es un atributo propio de los inputs que guarda lo que el usuario escribe. Son cosas distintas y se validan con funciones distintas.

¿Cómo encontrar la función correcta en la documentación de Playwright?

Abrir la documentación oficial y buscar attribute te lleva directo a expect(locator).toHaveAttribute(). Esta función recibe dos parámetros entre paréntesis: el nombre del atributo y el valor esperado.

• Primer parámetro: el tipo de atributo, en este caso value.
• Segundo parámetro: el texto que esperas encontrar, some random text.
• Locator: el elemento sobre el que aplicas la validación, aquí searchBox.

El patrón queda así de claro y reutilizable para cualquier input que necesites verificar más adelante.

¿Cómo se ve el cambio en el código?

En Visual Studio Code, comentas la línea que usaba toHaveText y la reemplazas con la nueva sintaxis. Tu locator sigue siendo searchBox, pero ahora la cadena de validación cambia a toHaveAttribute('value', 'some random text').

javascript await expect(searchBox).toHaveAttribute('value', 'some random text');

Al correr el test otra vez sin debug, termina en tres segundos y el reporte muestra todo en verde. Listo, segundo test resuelto.

¿Cómo usar el debugger y el inspector del navegador juntos?

La estrategia que destrabó el problema fue abrir el inspector de Playwright y las herramientas de desarrollador del navegador lado a lado [01:40]. Ejecutas el test en modo debug, escribes el texto en el input y antes de avanzar al siguiente paso usas clic derecho e inspeccionar sobre el campo.

Ahí confirmas que el elemento es de tipo input y que su contenido vive dentro de un atributo, no como texto. Ese hallazgo visual es lo que te empuja a buscar la función adecuada en la documentación.

¿Cuándo conviene usar el modo debug de Playwright? Cuando un test falla y el mensaje de error no es suficiente para entender la causa. El debug te deja pausar la ejecución, inspeccionar el DOM real y comparar lo que tu test espera contra lo que el navegador muestra.

¿Qué habilidades de testing estás practicando aquí?

Resolver este test combina varias capacidades que se usan a diario en QA automation:

• Lectura de tests escritos por otra persona para entender la intención detrás del código.
• Uso de herramientas de debugging como el inspector de Playwright y las DevTools del navegador.
• Consulta de documentación oficial para encontrar la función correcta cuando la primera opción no aplica.
• Diferenciación entre tipos de elementos HTML y sus formas de almacenar información.

Cada una de estas habilidades se refuerza cuando enfrentas un error real y lo resuelves paso a paso, no cuando memorizas sintaxis aislada.

¿Qué sigue después de resolver este test?

Queda un tercer test pendiente que funciona como proyecto final. Si lo resuelves y lo subes a la plataforma, obtienes el certificado de aprobación del curso. Cuéntame en los comentarios cómo se compara tu solución con la mía, qué cambiarías y qué te resultó más retador del proceso.