Video Summary and Transcription
Esta charla discute cómo probar el servicio de correo con Playwright, cubriendo la verificación de correo electrónico, el viaje del usuario para restablecer la contraseña y más. Explora el uso de proveedores de terceros para la entrega confiable de correos electrónicos y demuestra cómo Playwright puede ayudar a realizar comprobaciones en el contenido del correo electrónico. La charla también introduce el concepto de un servidor SMTP falso y muestra cómo se pueden usar los accesorios para acceder al servidor SMTP y realizar afirmaciones en el cuerpo HTML de los correos electrónicos. La función de renderizado HTML de Playwright permite interactuar con el contenido del correo electrónico como si fuera una página web regular. Destaca la capacidad de renderizar HTML a partir de llamadas API, realizar afirmaciones en la página renderizada y excluir datos generados dinámicamente de las pruebas de regresión visual.
1. Prueba del servicio de correo con Playwright
En esta charla, les mostraré cómo probar el servicio de correo con Playwright. Cubriremos la verificación de correo electrónico, el recorrido del usuario para restablecer la contraseña y más. Al usar proveedores de terceros como Amazon SES, MailChimp, Postmark o SendGrid, podemos garantizar una entrega de correo electrónico confiable. Sin embargo, el problema radica en lo que se entrega al usuario. Hoy, demostraré cómo Playwright puede ayudar a realizar controles en el contenido del correo electrónico y garantizar una experiencia de usuario fluida. Además, presentaré el concepto de un servidor SMTP falso, que captura y almacena correos electrónicos en un entorno de prueba. Herramientas como Mailhug proporcionan una interfaz fácil de usar para la verificación manual y una documentación de API completa.
Hola a todos, mi nombre es Kat Kniotek, trabajo como ingeniera de calidad en Zoopla, y gracias por unirse a mi charla hoy. Estaré hablando sobre testing el servicio de correo con Playwright. Les mostraré lo fácil que es agregar la verificación de correo electrónico o el recorrido del usuario para restablecer la contraseña a sus pruebas de extremo a extremo. Y sinceramente, me gusta mucho lo ingenioso que puedes ser aquí con Playwright. Así que comencemos.
Dependiendo de la aplicación en la que estés trabajando, puedes o no puedes comunicarte con el usuario por correo electrónico. Pero si lo haces, les enviarías boletines informativos, confirmaciones de pedidos. Si trabajas en el sitio web de e-commerce, enlace para restablecer la contraseña si la acción es solicitada por el usuario, solicitud de verificación de correo electrónico y cualquier tipo de recibos o notificaciones que puedan solicitar. Y generalmente usas proveedores de terceros para manejar esto, pueden transportarlo por ti. Y esos serían Amazon SES, MailChimp, Postmark y SendGrid, solo por nombrar algunos. Y es una muy buena idea porque podemos confiar en ellos para asegurarnos de que el correo electrónico se entregue realmente. Pero la declaración del problema de esta charla es lo que se entrega al usuario. ¿Pueden hacer clic en el enlace y restablecer su contraseña? ¿El correo electrónico de verificación realmente los lleva al dominio correcto? Si el contenido del cuerpo del correo electrónico realmente coincide con nuestro sistema de design, y por supuesto, si por error, no enviamos ningún data sensible o cualquier data aleatorio como esta prueba como asunto del correo electrónico. Así que hoy, les mostraré cómo se pueden realizar todas esas verificaciones con la ayuda de Playwright. Así que comencemos. Entonces, para describir la comunicación por correo electrónico en una aplicación de producción, tendrás la aplicación comunicándose con el servicio de terceros, y el servicio de terceros será responsable de entregar los correos electrónicos al usuario o a los grupos de usuarios. En un entorno de prueba para esta demostración, en lugar de enviar solicitudes al servicio de terceros, estaremos enviando correos electrónicos a un servicio SMTP falso y desde allí, podremos acceder a data desde las pruebas de Playwright. OK, acabo de introducir algo nuevo, un servidor SMTP falso, ¿qué es eso? Puedes pensar en ello como un contenedor que estará capturando y almacenando todos los correos electrónicos enviados por la aplicación en un entorno de prueba. Y para este propósito, puedes elegir una de las muchas herramientas disponibles. Aquí solo he enumerado algunas. Algunas de ellas son de pago y algunas de ellas son de código abierto. Depende de ti cuál usarás. Para esta demostración, estoy usando Mailhug. Todos ellos suelen venir con una interfaz de usuario gráfica muy agradable que puedes acceder en tu navegador que se ve exactamente como el buzón. Puedes navegar por los correos electrónicos, puedes eliminar correos electrónicos, almacenar archivos adjuntos o reenviar correos electrónicos. Es genial para la verificación manual de lo que se envía al usuario. Ese tipo de servidor SMTP falso también vendrá con una gran documentation sobre su API. Así que con Swagger. Swagger enumeraría todos los puntos finales disponibles en el servicio con los métodos que están disponibles y cómo debería verse la carga útil
2. Integrando la API de Mailhook con las pruebas de Playwright
Aquí está el ejemplo de llamada a la API de Mailhook, consultando los correos electrónicos enviados al usuario de prueba. La respuesta incluye el estado, el número de correos electrónicos enviados y los objetos de correo electrónico con ID, de, para, contenido y cuerpo. Podemos realizar afirmaciones sobre el contenido del correo electrónico, incluyendo la comprobación de cadenas específicas, elementos y estilos. Para traducir esta prueba de API a las pruebas de Playwright, necesitamos acceder al servidor SMTP, recuperar el correo electrónico más reciente y realizar afirmaciones sobre el cuerpo HTML. La función de renderizado HTML de Playwright nos permite interactuar con el contenido del correo electrónico como si fuera una página web regular. Podemos hacer clic en enlaces, comprobar elementos y verificar URLs. Para empezar, accederemos al servidor SMTP desde nuestras pruebas de extremo a extremo utilizando fixtures, que proporcionan contextos aislados con configuraciones separadas.
como y qué esperas ver como respuesta de la llamada API al servidor. Aquí está la captura de pantalla del ejemplo de llamada a la API de Mailhook. Así que como punto de búsqueda estoy consultando aquí. Basado en su documentation, proporcioné parámetros de consulta para obtener todos los correos electrónicos que han sido enviados al usuario de prueba en example.com y en el lado derecho, puedes ver cómo se ve la respuesta. Tan bueno, porque el estado es 200. Y luego puedes ver cuántos correos electrónicos han sido enviados a este usuario, así que el punto final del servicio devuelve tres. Brillante, porque estaba solo testing un poco. Y todos ellos están listados como objetos de correo electrónico en el array de items, así en la línea cinco, y cada objeto de correo electrónico individual tendría ID, de, para, contenido y cuerpo. Y si miras más de cerca, debajo de la línea 34, bueno, desde la línea 34, puedes ver que el cuerpo es en realidad cuerpo HTML, código HTML. Así que de nuevo, aquí también podemos hacer algunas afirmaciones. Podemos comprobar si ciertas cadenas están presentes, si ciertos elementos están presentes, digamos un botón o un enlace, pero también verificar si se ha aplicado el estilo, ¿verdad? Sólo para mencionar, estoy usando Thunder Client aquí. Así que, herramientas similares a Postman o Insomnia, si estás familiarizado con ellas. Bueno, así que, un servidor SMTP falso viene con algunas características agradables que permiten la testing manual, pero usaremos el mismo servidor SMTP en nuestras pruebas de Playwright, así que veamos cómo traducir lo que acabo de mostrar con, digamos, la testing de API a las pruebas de Playwright. Empecemos con la codificación pseudo, ¿qué queremos hacer? Así que, primero, nuestra prueba necesitará tener una precondición y eso depende de tu aplicación. Eso podría ser la acción que desencadena el envío de la verificación por correo electrónico. Digamos, el usuario crea la cuenta o el usuario completa el pedido y se envía la confirmación del pedido y así sucesivamente. Como no estoy conectando a ninguna aplicación real aquí, era sólo un script que desencadena el envío de correo electrónico. Bueno, así que ¿en qué queremos centrarnos en la prueba? Queremos hacer exactamente lo que hice manualmente con la conexión al servidor SMTP. Así que, quiero acceder al servidor SMTP, quiero obtener el correo electrónico más reciente que ha sido enviado al usuario. Así que, en una respuesta había un array de items, así que quiero obtener el primer elemento de él, así con el índice cero. Y quiero obtener una parte del cuerpo HTML, porque ahí es donde quiero hacer afirmaciones. Y la gran característica mágica de Playwright, puedes usar este cuerpo HTML para renderizar una nueva página y hacer las mismas afirmaciones que harías en una página regular en un navegador. Así que, puedes hacer clic en el botón de verificación, puedes comprobar si ciertos elementos están presentes y también puedes verificar si al hacer clic en el botón de verificación, se abrirá una nueva pestaña y puedes hacer una afirmación si la nueva pestaña que es también página, tendrá la URL esperada. Bueno, así que, eso es mucho que hacer. Así que, ¿por dónde empezar? Empezaré accediendo al servidor SMTP desde mis pruebas de extremo a extremo. Y para este propósito, estaré usando fixtures. ¿Qué son los fixtures? Así que, probablemente en tu aplicación, tienes Configuración de Playwright. Bueno, en tus pruebas de extremo a extremo, tienes Configuración de Playwright y especificas el valor de la URL base allí. Y eso sería el frente de tu aplicación cliente code, la URL base de tus viejas pruebas. Pero también puedes especificar fixtures, así como contextos aislados que se utilizarán en una cierta prueba. Así que, aquí estoy creando el fixture llamado email API
3. Accediendo al servidor SMTP con Fixtures
Los fixtures te permiten agregar diferentes pruebas de endpoint desde el mismo repositorio. El contexto de la API se define en la línea 11 y se utiliza para todas las llamadas realizadas a la API de correo electrónico. En la línea 14, se utiliza el método get para consultar el endpoint de búsqueda y devolver la respuesta. El cuerpo HTML del correo electrónico más reciente se obtiene en la línea 26, y cualquier codificación se limpia en la línea 28. Luego, el cuerpo HTML se utiliza para renderizar la página de correo electrónico e interactuar con ella. La prueba consta de precondiciones, utilizando la API de correo electrónico para obtener el cuerpo del correo electrónico, renderizar la página de correo electrónico, hacer clic en un botón y afirmar la URL de la nueva pestaña abierta.
y ese tendrá un valor de URL base separado, encabezados HTTP adicionales y así sucesivamente. Así, esos fixtures te permiten agregar tal vez diferentes pruebas de endpoint desde el mismo repositorio de pruebas también backend u otros servicios como aquí ejemplo, Mailhook. Así que, como puedes ver, proporciono el valor de la URL base que está ejecutándose en el servidor Mailhook de localhost. Paso la autorización como encabezados HTTP adicionales y también especifico ignorar los errores HTTP como verdadero porque estoy intentando conectarme a localhost. Y este contexto de la API se define en la línea 11, se utilizará en todas las llamadas realizadas a la API de correo electrónico.
Vale, y cómo se ve realmente cuando lo usas. Así que, en la línea 14, aquí veo que puedo ver que sí, en el lado izquierdo probablemente no veas este 14, es 14, línea 14, hago exactamente lo mismo lo que hice en el cliente Tandr ya sea manualmente testing endpoint. Así que, en el contexto de la API que acabo de definir, utilizo el método get para consultar el endpoint de búsqueda para los parámetros de consulta lo mismo que en el ejemplo del cliente Tandr. Así que, consulto todos los correos electrónicos que han sido enviados al usuario de prueba y luego devuelvo la respuesta.
Y aquí, esto puede parecer un poco complejo, ¿qué está pasando aquí? Aquí en la línea 26, obtengo el primer correo electrónico, así que los ítems índice uno, contenido y cuerpo para obtener el cuerpo HTML del correo electrónico más reciente que ha sido enviado al usuario. Lo que está pasando en la línea 26 puede parecer un poco confuso, así que cuando estaba mostrando en un cliente tierno cómo se ve el cuerpo, el cuerpo HTML del correo electrónico, tal vez notaste que se añadieron cadenas iguales 3D en algunos lugares. Esto se debe al tipo de codificación utilizado para el transporte de correo electrónico llamado imprimible citado. Así que aquí en la línea 28, simplemente ordeno el cuerpo del correo electrónico de esta codificación. Parece complejo, pero confío en las bibliotecas de ayuda para hacerlo por mí. Y luego al final, simplemente devuelvo el cuerpo HTML. Así que ahora este cuerpo HTML se puede utilizar para renderizar la página. Así que aquí en un objeto de página de correo electrónico, defino mi método personalizado de ir a. Que toma como parámetro, en realidad el HTML code del correo electrónico. Y en la línea 14, instruyo a Playwright. Cada vez que estaría yendo a la URL de correo electrónico de barra inclinada, quiero que esta solicitud de ruta sea cumplida con el cuerpo del correo electrónico. Así que entonces cuando en la línea 16 realmente voy a esta URL, lo que se renderizará en el navegador será en realidad el cuerpo del correo electrónico. Y entonces podré interactuar con él como lo haría con cualquier página. Así que estaré haciendo clic en el botón de verificación en la línea 22 y esperaré hasta que se abra una nueva pestaña y devolveré la nueva pestaña. Poniéndolo todo junto en la línea 15, básicamente así es como se verá la prueba se verá, así que obviamente primero la precondición. Pero entonces como dije, especifico el separado fixture así que así es como lo importé a las pruebas particulares, email API en la línea 15. Así que, entonces uso la API de correo electrónico para obtener el cuerpo del correo electrónico en la línea 18 para el usuario de prueba, el usuario de prueba que uso para la verificación manual también. Una vez que tengo este cuerpo HTML en línea, creo que es la línea 12, puedo usar este cuerpo HTML para renderizar la página de correo electrónico, hacer clic en el botón de esta página de correo electrónico y luego afirmar que en realidad la URL de esta nueva pestaña abierta coincide con test.js summit. Vale, eso puede funcionar, puede que no, pero si ejecuto la prueba en realidad en un modo debug, puedo ver el navegador abriéndose y el Inspector de Playwriting abriéndose a su lado, así que puedo dar un paso desde la prueba y ver que realmente funciona. Así que ¿qué está pasando aquí? Esa es la primera página que se abre, porque la llamada a la API ocurre en segundos, justo antes de que se abra el navegador. Así que aquí estamos en el paso que voy a la barra inclinada de correo electrónico, y el correo electrónico se renderiza realmente. Y aquí, el jugador intenta hacer clic en el botón del elemento con
4. Técnicas Avanzadas de Prueba de Correo Electrónico con Playwright
Puedes usar Playwright para renderizar HTML a partir de llamadas a la API y realizar afirmaciones en la página renderizada. Playwright te permite excluir datos generados dinámicamente de las pruebas de regresión visual. Con Playwright, puedes verificar si los correos electrónicos son entregados, verificar la funcionalidad de los botones y realizar afirmaciones en los elementos del DOM. Los enlaces proporcionados incluyen Mailhook Swagger, una imagen Docker de Mailhook con OAuth, e información sobre la codificación igual 3D y el cliente Tandr para pruebas manuales de la API.
ID Button 1. Y una vez que eso es exitoso, se abre la nueva pestaña. Y como puedes ver, la URL es exactamente la que esperábamos que apareciera aquí. Así que cuando lo vi por primera vez, estaba como, guau, eso es increíble. Realmente puedes obtener HTML de la llamada a la API y usar este HTML para renderizar la página. Sí, es increíble. Y a partir de aquí, puedes pensar cuántas otras afirmaciones podrías hacer en la página realmente renderizada. Así que puedes hacer pruebas de regresión visual. Así que hacer la comparación de capturas de pantalla para asegurarte de que nada ha cambiado en la versión del correo electrónico que estás enviando ahora en comparación con la imagen de referencia. Aquí puedes decir, vale, envié al usuario como un título o, no sé, un encabezado del correo electrónico. Rendericé su nombre de usuario o su primer nombre o iniciales. Y eso será diferente con cada ejecución de la prueba, porque generas dinámicamente los datos de prueba data. Así que aquí con la API de Playwright, puedes excluir esta área de la comparación. Así que digamos que enmascaramos el localizador H1. Y eso te ayudará con la prueba del correo electrónico si los datos se generan dinámicamente. También puedes, como mencioné, una vez que tenemos este correo electrónico renderizado como una página, puedes hacer todo tipo de afirmaciones como las que harías en una página regular. Así que digamos que comprueba que el botón de verificación realmente tiene el atributo correcto o si el estado cambia cuando pasas el ratón por encima y así sucesivamente. Así que espero que haya mostrado cómo se puede usar Playwright para probar el cuerpo del correo electrónico y lo que realmente se envía al usuario. Así que comprobé que el correo electrónico fue entregado al usuario. Comprobé la funcionalidad del botón, así que pudiste ver que el clic de acción ha sido exitoso, que la navegación ocurrió a la URL correcta. Con Playwright también puedes hacer una comprobación visual en el correo electrónico, en el cuerpo del contenido y obviamente todas las demás afirmaciones en los elementos del DOM como lo harías. OK, eso es el final de la charla. Espero que la hayas encontrado útil y los enlaces que acabo de publicar aquí te ayudarán a quizás intentar y construir una solución similar y aplicarla a tus pruebas. Como mencioné, estaba usando Mailhook, así que proporcioné un enlace a Mailhook Swagger. Imagen de docker de Mailhook con OAuth para que puedas ejecutarla localmente. Más explicación sobre igual 3D, así que la codificación imprimible citada. Unas pocas palabras sobre el cliente Tandr, así que mi herramienta preferida para pruebas manuales de la API y enlace para contactar conmigo si tuvieras alguna pregunta. Así que, sí, espero con interés escuchar tus preguntas ahora. Si quieres acceder a la presentación, puedes simplemente escanear el código QR code y eso te llevará a las diapositivas. Gracias.
Comments