Probando el servicio de correo con Playwright

Rate this content
Bookmark

Enviamos correos electrónicos a nuestros usuarios: verificación de cuenta y boletines informativos. Permitimos al usuario ponerse en contacto con nosotros enviando un correo electrónico a través de un formulario incorporado. ¿Lo hacemos? ¿Recibe el usuario un correo electrónico de verificación de cuenta o exactamente qué notificación se registró? Podemos cubrir esta funcionalidad como parte de las pruebas de extremo a extremo: obtener un correo electrónico y abrirlo para verificar qué contiene. Necesitaremos Playwright y un servidor SMTP falso para capturar los correos electrónicos enviados por la aplicación.

17 min
03 Nov, 2022

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 proceso de restablecimiento de 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 utilizar fixtures para acceder al servidor SMTP y realizar afirmaciones sobre 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 normal. Destaca la capacidad de renderizar HTML a partir de llamadas a la API, realizar afirmaciones sobre la página renderizada y excluir datos generados dinámicamente de las pruebas de regresión visual.

Available in English

1. Testing Mail Service with Playwright

Short description:

En esta charla, te mostraré cómo probar el servicio de correo con Playwright. Cubriremos la verificación de correo electrónico, el proceso de restablecimiento de contraseña y más. Al utilizar proveedores de terceros como Amazon SES, MailChimp, Postmark o SendGrid, podemos garantizar la entrega confiable de correos electrónicos. Sin embargo, el problema radica en lo que se entrega al usuario. Hoy, demostraré cómo Playwright puede ayudar a realizar verificaciones 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 verificaciones manuales y documentación de API completa.

Hola a todos, mi nombre es Kat Kniotek, trabajo como ingeniera de calidad en Zoopla, y les agradezco por unirse a mi charla hoy. Hablaré sobre la prueba del servicio de correo con Playwright. Les mostraré lo fácil que es agregar la verificación de correo electrónico o el proceso de restablecimiento de contraseña a sus pruebas de extremo a extremo. Y sinceramente, me gusta mucho lo inteligente que puedes ser aquí con Playwright. Así que empecemos.

Dependiendo de la aplicación en la que estés trabajando, es posible que te comuniques o no con el usuario por correo electrónico. Pero si lo haces, les enviarías boletines informativos, confirmaciones de pedidos. Si trabajas en un sitio web de comercio electrónico, enviarías un enlace para restablecer la contraseña si la acción es solicitada por el usuario, una solicitud de verificación de correo electrónico y cualquier tipo de recibos o notificaciones que puedan solicitar. Y generalmente utilizas proveedores de terceros para manejar esto, pueden encargarse del transporte por ti. Algunos de estos proveedores son Amazon SES, MailChimp, Postmark y SendGrid, solo por mencionar algunos. Y es una muy buena idea porque podemos confiar en ellos para asegurarnos de que el correo electrónico se entregue correctamente. Pero el problema que plantea esta charla es qué se entrega al usuario. ¿Pueden hacer clic en el enlace y restablecer su contraseña? ¿La verificación de correo electrónico los lleva al dominio correcto? ¿El contenido del cuerpo del correo electrónico coincide con nuestro sistema de diseño? Y, por supuesto, si por error no enviamos ningún dato sensible o datos aleatorios como `test` como asunto del correo electrónico. Así que hoy les mostraré cómo se pueden realizar todas estas verificaciones con la ayuda de Playwright. Así que empecemos. Para describir la comunicación por correo electrónico en una aplicación de producción, tendrás la aplicación comunicándose con un servicio de terceros, y el servicio de terceros será responsable de entregar correos electrónicos al usuario o grupos de usuarios. En un entorno de prueba para esta demostración, en lugar de enviar solicitudes al servicio de terceros, enviaremos correos electrónicos a un servicio SMTP falso y desde allí podremos acceder a los datos desde las pruebas de Playwright. OK, acabo de presentar algo nuevo, un servidor SMTP falso, ¿qué es? Puedes pensar en él como un contenedor que capturará y almacenará 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. Enumeré solo algunas aquí. Algunas de ellas son de pago y otras son de código abierto. Depende de ti cuál usarás. Para esta demostración, estoy usando Mailhug. Todas ellas suelen venir con una interfaz gráfica de usuario realmente agradable a la que puedes acceder en tu navegador y que se parece exactamente a una bandeja de entrada de correo. Puedes navegar por los correos electrónicos, eliminarlos, almacenar archivos adjuntos o reenviar correos electrónicos. Es genial para verificar manualmente lo que se envía al usuario. Ese tipo de servidor SMTP falso también vendrá con una excelente documentación sobre su API. Por ejemplo, Swagger. Swagger enumerará todos los puntos finales disponibles en el servicio con los métodos que están disponibles y cómo debe ser el cuerpo de la solicitud.

2. Integración de la API de Mailhook con las pruebas de Playwright

Short description:

Aquí tienes 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, remitente, destinatario, contenido y cuerpo. Podemos realizar afirmaciones en el contenido del correo electrónico, incluyendo la verificación de cadenas específicas, elementos y estilos. Para traducir estas pruebas de API a pruebas de Playwright, necesitamos acceder al servidor SMTP, recuperar el correo electrónico más reciente y realizar afirmaciones en 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 normal. Podemos hacer clic en enlaces, verificar elementos y verificar URL. Para empezar, accederemos al servidor SMTP desde nuestras pruebas de extremo a extremo utilizando fixtures, que proporcionan contextos aislados con configuraciones separadas.

Me gustaría mostrarte cómo se ve una llamada de ejemplo a la API de Mailhook y qué esperar como respuesta del servidor. Aquí tienes la captura de pantalla de la llamada de ejemplo a la API de Mailhook. Como punto de búsqueda, estoy consultando aquí. Según su documentación, proporcioné parámetros de consulta para obtener todos los correos electrónicos enviados al usuario de prueba en example.com y en el lado derecho puedes ver cómo se ve la respuesta. Está bien porque el estado es 200. Y luego puedes ver cuántos correos electrónicos se han enviado a este usuario, por lo que el punto final del servicio devuelve tres. Genial, porque solo estaba probando un poco. Y todos ellos están listados como objetos de correo electrónico en la matriz de elementos, así que en la línea cinco, y cada objeto de correo electrónico individual tendrá ID, remitente, destinatario, contenido y cuerpo. Y si te fijas más de cerca, debajo de la línea 34, bueno, desde la línea 34, puedes ver que el cuerpo es en realidad un cuerpo HTML, código HTML. Así que aquí también podemos hacer algunas afirmaciones. Podemos verificar 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? Solo para mencionar, estoy usando Thunder Client aquí. Son herramientas similares a Postman o Insomnia, si estás familiarizado con ellas. Bien, un servidor SMTP falso viene con algunas características interesantes que permiten pruebas manuales, pero usaremos el mismo servidor SMTP en nuestras pruebas de Playwright, así que veamos cómo traducir lo que acabo de mostrar con las pruebas de API a las pruebas de Playwright. Comencemos con un seudocódigo, ¿qué queremos hacer? Entonces, primero, nuestra prueba deberá tener una precondición y eso depende de tu aplicación. Podría ser la acción que desencadena el envío de verificación por correo electrónico. Digamos que el usuario crea una cuenta o utiliza completa el pedido y se envía la confirmación del pedido, y así sucesivamente. Como no estoy conectándome a ninguna aplicación real aquí, solo fue un script que desencadena el envío de correo electrónico. Bien, ¿en qué queremos enfocarnos en la prueba? Queremos hacer exactamente lo que hice manualmente al conectarme al servidor SMTP. Entonces, quiero acceder al servidor SMTP, quiero obtener el correo electrónico más reciente que se ha enviado al usuario. Por lo tanto, en la respuesta había una matriz de elementos, así que quiero obtener el primer elemento de ella, es decir, con í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 es que 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. Por lo tanto, puedes hacer clic en un botón de verificación o enlace, puedes verificar 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 también es una página, tendrá la URL esperada. Bien, eso es mucho por hacer. ¿Por dónde empezar? Comenzaré accediendo al servidor SMTP desde mis pruebas de extremo a extremo. Y para este propósito, utilizaré fixtures. ¿Qué son los fixtures? Probablemente en tu aplicación, tienes Playwright Config. Bueno, en tus pruebas de extremo a extremo, tienes Playwright Config y especificas el valor de la URL base allí. Y eso sería el front-end de tu código de cliente de la aplicación, la URL base de tus pruebas antiguas. Pero también puedes especificar fixtures, como contextos aislados que se utilizarán en una prueba determinada. Así que aquí estoy creando el fixture llamado email API.

3. Accediendo al servidor SMTP con Fixtures

Short description:

Los fixtures te permiten agregar diferentes pruebas de punto final 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 punto final 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 se limpia cualquier codificación en la línea 28. Luego, se utiliza el cuerpo HTML para renderizar la página del correo electrónico e interactuar con ella. La prueba consiste en precondiciones, utilizando la API de correo electrónico para obtener el cuerpo del correo electrónico, renderizando la página del correo electrónico, haciendo clic en un botón y verificando la URL de la nueva pestaña abierta.

y ese tendrá un valor de URL base separado, encabezados HTTP adicionales, y así sucesivamente. Entonces, esos fixtures te permiten agregar quizás diferentes pruebas de punto final desde el mismo repositorio, también pruebas de backend u otros servicios como aquí, por ejemplo, Mailhook. Como puedes ver, proporciono el valor de URL base que se ejecuta en el servidor de Mailhook local. Paso la autorización como encabezados HTTP adicionales y también especifico que ignore los errores HTTP como verdadero porque estoy intentando conectarme a localhost. Y este contexto de API se define en la línea 11 y se utilizará en todas las llamadas realizadas a la API de correo electrónico.

De acuerdo, ¿y cómo se ve realmente cuando lo usas? Entonces, en la línea 14, aquí puedo ver que sí, en el lado izquierdo probablemente no veas este 14, es el 14, línea 14, hago exactamente lo mismo que hice en el cliente de Thunder cuando estaba probando manualmente el punto final. Entonces, en el contexto de la API que acabo de definir, uso el método 'get' para consultar el punto final de búsqueda con los parámetros de consulta iguales que en el ejemplo del cliente de Thunder. Así que consulto todos los correos electrónicos que se han enviado al usuario de prueba y luego devuelvo la respuesta.

Y aquí, esto puede parecer un poco complejo, ¿qué está sucediendo aquí? Aquí, en la línea 26, obtengo el primer correo electrónico, el contenido y el cuerpo para obtener el cuerpo HTML del correo electrónico más reciente que se ha enviado al usuario. Lo que sucede en la línea 26 puede parecer un poco confuso, así que cuando estaba mostrando en el cliente de Thunder cómo se veía el cuerpo, el cuerpo HTML del correo electrónico, tal vez notaste que se agregaron cadenas 'equals 3D' en algunos lugares. Esto se debe al tipo de codificación utilizada para el transporte de correo electrónico llamada quoted printable. Entonces, aquí en la línea 28, simplemente limpio 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 al final, simplemente devuelvo el cuerpo HTML. Ahora este cuerpo HTML se puede utilizar para renderizar la página. Entonces, aquí en un objeto de página de correo electrónico, defino mi método personalizado 'go to' que toma como parámetro, en realidad, el código HTML del correo electrónico. Y en la línea 14, instruyo a Playwright. Cada vez que vaya a la URL '/email', quiero que esta solicitud de ruta se cumpla con el cuerpo del correo electrónico. Entonces, cuando en la línea 16 realmente vaya a esta URL, lo que se renderizará en el navegador será el cuerpo del correo electrónico. Y luego podré interactuar con él como lo haría con cualquier página. Así que haré 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í se verá la prueba, obviamente primero las precondiciones. Pero luego, como dije, especifico el fixture separado, así es como lo importé a las pruebas particulares, API de correo electrónico en la línea 15. 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 también uso para la verificación manual. 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 del correo electrónico, hacer clic en el botón de esta página de correo electrónico y luego verificar que la URL de esta nueva pestaña abierta coincida con test.js summit. De acuerdo, eso puede funcionar o no, pero si ejecuto la prueba en modo debug realmente, puedo ver que se abre el navegador y se abre el Inspector de Playwriting junto a él, así que puedo paso desde la prueba y ver que realmente funciona. Entonces, ¿qué está sucediendo aquí? Esta es la primera página real 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 en el que voy a '/email', y el correo electrónico se renderiza realmente. Y aquí, Playwright intenta hacer clic en el elemento del botón con

4. Técnicas Avanzadas de Pruebas de Correo Electrónico con Playwright

Short description:

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 se entregan los correos electrónicos, 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 a 3D y el cliente Tandr para pruebas manuales de la API.

ID Botón 1. Y una vez que ese sea exitoso, se abrirá una 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! Puedes obtener HTML de la llamada a la API y usar este HTML para renderizar la página. Sí, es asombroso. Y a partir de aquí, puedes pensar en cuántas otras afirmaciones podrías hacer en la página renderizada. Así que puedes hacer pruebas de regresión visual. Así que haz la comparación de capturas de pantalla para asegurarte de que nada haya 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, bien, lo envié al usuario como tal vez un título o, no sé, un encabezado del correo electrónico. Rendericé su nombre de usuario o su nombre o iniciales. Y eso será diferente en cada ejecución de prueba, porque generas dinámicamente los datos de prueba. Así que aquí, con la API de Playwright, puedes excluir esta área de la comparación. Digamos que ocultas 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 tengamos este correo electrónico renderizado como una página, puedes hacer todo tipo de afirmaciones como lo harías en una página regular. Así que digamos que verificas que el botón de verificación realmente tiene el atributo correcto o si el estado cambia cuando pasas el cursor sobre él, y así sucesivamente. Espero haber mostrado cómo se puede usar Playwright para probar el cuerpo del correo electrónico y lo que realmente se envía al usuario. Verifiqué que el correo electrónico se entregó al usuario. Verifiqué la funcionalidad del botón para que puedas ver que la acción de clic fue exitosa, y que la navegación se realizó a la URL correcta. Con Playwright también puedes hacer una verificación visual del correo electrónico, del contenido del cuerpo y, obviamente, todas las demás afirmaciones en los elementos del DOM como lo harías normalmente. OK, eso es el final de la charla. Espero que te haya resultado útil y los enlaces que acabo de publicar aquí te ayuden a intentar construir una solución similar y aplicarla a tus pruebas. Como mencioné, estaba usando Mailhook, así que proporcioné un enlace a Mailhook Swagger. Una imagen Docker de Mailhook con OAuth para que puedas ejecutarlo localmente. Más explicación sobre igual 3D, que es la codificación quoted printable. Algunas palabras sobre el cliente Tandr, que es mi herramienta principal para pruebas manuales de la API, y un enlace para contactarme si tienes alguna pregunta. Así que sí, espero con ansias escuchar tus preguntas ahora. Si quieres acceder a la presentación, simplemente escanea el código QR y te llevará a las diapositivas. Gracias.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
JSNation Live 2021JSNation Live 2021
29 min
Making JavaScript on WebAssembly Fast
Top Content
JavaScript in the browser runs many times faster than it did two decades ago. And that happened because the browser vendors spent that time working on intensive performance optimizations in their JavaScript engines.Because of this optimization work, JavaScript is now running in many places besides the browser. But there are still some environments where the JS engines can’t apply those optimizations in the right way to make things fast.We’re working to solve this, beginning a whole new wave of JavaScript optimization work. We’re improving JavaScript performance for entirely different environments, where different rules apply. And this is possible because of WebAssembly. In this talk, I'll explain how this all works and what's coming next.
React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
TestJS Summit 2022TestJS Summit 2022
27 min
Full-Circle Testing With Cypress
Top Content
Cypress has taken the world by storm by brining an easy to use tool for end to end testing. It’s capabilities have proven to be be useful for creating stable tests for frontend applications. But end to end testing is just a small part of testing efforts. What about your API? What about your components? Well, in my talk I would like to show you how we can start with end-to-end tests, go deeper with component testing and then move up to testing our API, circ
TestJS Summit 2022TestJS Summit 2022
20 min
Testing Web Applications with Playwright
Top Content
Testing is hard, testing takes time to learn and to write, and time is money. As developers we want to test. We know we should but we don't have time. So how can we get more developers to do testing? We can create better tools.Let me introduce you to Playwright - Reliable end-to-end cross browser testing for modern web apps, by Microsoft and fully open source. Playwright's codegen generates tests for you in JavaScript, TypeScript, Dot Net, Java or Python. Now you really have no excuses. It's time to play your tests wright.

Workshops on related topic

React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
Top Content
WorkshopFree
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
React Day Berlin 2022React Day Berlin 2022
86 min
Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
Top Content
WorkshopFree
Using a library might seem easy at first glance, but how do you choose the right library? How do you upgrade an existing one? And how do you wade through the documentation to find what you want?
In this workshop, we’ll discuss all these finer points while going through a general example of building a code editor using CodeMirror in React. All while sharing some of the nuances our team learned about using this library and some problems we encountered.
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.JS backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
Table of contents- A quick intro to core authentication concepts- Coding- Why passwordless matters
Prerequisites- IDE for your choice- Node 18 or higher
React Summit US 2023React Summit US 2023
96 min
Build a powerful DataGrid in few hours with Ag Grid
WorkshopFree
Does your React app need to efficiently display lots (and lots) of data in a grid? Do your users want to be able to search, sort, filter, and edit data? AG Grid is the best JavaScript grid in the world and is packed with features, highly performant, and extensible. In this workshop, you’ll learn how to get started with AG Grid, how we can enable sorting and filtering of data in the grid, cell rendering, and more. You will walk away from this free 3-hour workshop equipped with the knowledge for implementing AG Grid into your React application.
We all know that rolling our own grid solution is not easy, and let's be honest, is not something that we should be working on. We are focused on building a product and driving forward innovation. In this workshop, you'll see just how easy it is to get started with AG Grid.
Prerequisites: Basic React and JavaScript
Workshop level: Beginner
TestJS Summit 2023TestJS Summit 2023
89 min
Building out a meaningful test suite that's not all E2E
Workshop
We're all taught to follow the Testing Pyramid but the reality is that we build out the Testing Christmas Tree. In this workshop, David will talk you through how to break down projects and put the tests where they need to be. By the end of the workshop you will be able to update your projects so that anyone and everyone can start contributing and truly living up to "Quality is everyone job".
He will walk you through:- Component Testing- API Testing- Visual Regression Testing- A11Y testing
He will also talk you through how to get these all setup in your CI/CD pipeline so that you can get shorter and faster feedback loops.