Adaptación de las Pruebas E2E para un Gran Proyecto

Rate this content
Bookmark

DeliveryHero es una gran empresa internacional. Y como en toda gran empresa, la introducción de una nueva mejora técnica es un tema candente. Conozca los desafíos que nuestro equipo enfrentó al hacer que nuestra plataforma sea probada de extremo a extremo, cómo mejoraron nuestros mecanismos de informes con el tiempo y las soluciones que desarrollamos para probar diferentes variaciones de una función.

8 min
18 Jun, 2021

Video Summary and Transcription

Esta Charla presenta la adaptación de las pruebas de extremo a extremo para un proyecto, destacando sus beneficios en la mejora de la resiliencia y la tranquilidad durante la implementación. El orador menciona el tamaño del equipo, las solicitudes de extracción diarias y el tamaño de su base de código. También discuten el uso de cookies para probar diferentes versiones de una función en una página y su plan de mejora mediante la adición de pruebas E2E a un pipeline de CICD y la consolidación de pruebas en su monorepo.

Available in English

1. Introducción a las pruebas de extremo a extremo y configuración

Short description:

Hola, soy Vadim, un ingeniero de front-end de Delivery Hero, y hoy con mi colega Devesh, quiero presentarles la adaptación de las pruebas de extremo a extremo que hemos realizado para nuestro proyecto. Pensamos que es una gran mejora introducir las pruebas de extremo a extremo para mejorar nuestra resistencia y tranquilidad al implementar un gran cambio. Tenemos más de 20 desarrolladores de front-end, hacemos 10 solicitudes de extracción diarias y nuestro repositorio de micro-front-ends tiene más de 50 mil líneas de código en total sin incluir los módulos de nodo. La configuración de las pruebas de extremo a extremo es un repositorio separado y las ejecutamos como un trabajo programado. También utilizamos las mejores prácticas del equipo de Cypress y los principios de accesibilidad en las pruebas. Ahora, quiero cederle la palabra a Dinesh.

y hoy con mi colega Devesh, quiero presentarles la adaptación de las pruebas de extremo a extremo que hemos realizado para nuestro proyecto en Delivery Hero. El orden del día para hoy será el estudio de caso para las pruebas de extremo a extremo, o por qué comenzamos a hacerlo, la configuración de las pruebas de extremo a extremo, y las mejores prácticas que utilizamos, luego cómo evitar repetir este ciclo durante el desarrollo de las pruebas, y cómo estamos probando diferentes variaciones de la funcionalidad. Entonces, el estudio de caso para las pruebas de extremo a extremo fue bastante simple y común como para todos, porque Delivery Hero es una gran empresa con un gran proyecto de front-end, lleva mucho tiempo y esfuerzo mantenerlo y desarrollarlo, así que pensamos que es una gran mejora para la situación introducir las pruebas de extremo a extremo para no tener que probar manualmente las funcionalidades cada vez o depurar correcciones, así que podemos mejorar nuestra resistencia y la tranquilidad al implementar un gran cambio. Para tener una idea de la escala, tenemos más de 20 desarrolladores de front-end, hacemos 10 solicitudes de extracción diarias, nuestro repositorio de micro-front-ends tiene más de 50 mil líneas de código en total sin incluir los módulos de nodo, y el monolito tiene el antiguo monolito tiene 200 mil líneas de código en total, así que es bastante grande. La configuración de las pruebas de extremo a extremo que tenemos es básicamente un repositorio separado, porque agregamos las pruebas mientras nos estábamos migrando del antiguo proyecto al mono-repo con los micro-front-ends, y tenemos la simplicidad de ejecutar las pruebas en el repositorio separado para que los desarrolladores puedan incorporarse fácilmente. Por ahora, las ejecutamos como un trabajo programado, sí, sabemos que no es un estándar, digamos, pero estamos trabajando en la integración con los pipelines de CICD, y creamos nuestra propia integración personalizada de Slack con Cypress. Sabemos que hay un complemento oficial desarrollado la semana pasada, pero sí, todavía tenemos el nuestro por ahora. Sí, puedes ver el ejemplo de cómo es el mensaje del bot de Slack con el informe, y puedes hacer clic en el botón de informe y verificar este tipo de informe, que es muy útil porque muestra como la traza de la pila, el error exacto y la captura de pantalla. También, por supuesto, estamos utilizando algunas mejores prácticas del equipo de Cypress y algunas propias, que intentan utilizar los principios de accesibilidad en las pruebas creadas por Ken Dodds, el creador de la biblioteca de pruebas. En lugar de utilizar data CI, que es una mejor práctica del equipo de Cypress, podemos utilizar los atributos de área y otros atributos de accesibilidad, que son muy útiles y prácticos. También, por supuesto, utilizamos los comandos de Cypress para ayudantes generales, como si algo se utiliza en especificaciones separadas o más de dos veces, simplemente lo envolvemos en el comando y lo usamos como una sola línea, lo cual es más sencillo. Además, estamos utilizando una anotación de given, pero no solo como una estructura para la prueba, sino también, como un comando, porque como puedes ver aquí en un ejemplo, es muy útil, porque incluso si eliminas todo el código, aún tienes una idea de qué va a probar la prueba, porque a veces los comandos pueden ser complicados. Y ahora, quiero cederle la palabra a Dinesh, por favor. Gracias, Vadim. Hola a todos. Vadim mencionó escenarios bastante buenos sobre las mejores prácticas que estamos siguiendo. Así que, voy a guiarlos sobre dos cosas en particular que estamos haciendo en nuestro equipo, que realmente nos ayuda a lograr una prueba muy rápidamente. Entonces, una de estas cosas en particular es cómo evitar repetir el ciclo. Quiero decir, la mayoría de las pruebas de extremo a extremo que se ven hoy en día son como un flujo único. Primero, el usuario, quiero decir, primero la prueba de extremo a extremo pasa por una página, luego la segunda página y la tercera página. Es de manera secuencial. Pero considerando que somos un equipo de más de 20 desarrolladores, como mencionó Vadym, y diferentes equipos están trabajando en diferentes páginas o diferentes módulos, no queremos repetir todo el ciclo durante el desarrollo. Queremos probar nuestras funcionalidades, queremos probar solo nuestra página. Entonces, esto sería algo así, ¿de acuerdo? Ir directamente desde una página a nuestra página. Entonces, ¿cómo lo estamos logrando realmente? Creamos un servicio de utilidad en nuestras utilidades. Quiero decir, no es una utilidad, pero podríamos decir un comando que Vadym mencionó. Tenemos un comando personalizado, que es ir a la página. Entonces, ¿qué sucede en este comando en particular? Esto podría ser cualquier página. Como, esto podría ser ir a mi página y luego puedo marcar los datos anteriores sobre todas las páginas que vinieron antes, como todos los datos que agregaron al navegador, al almacenamiento, todo será

2. Pruebas de Diferentes Versiones de una Funcionalidad

Short description:

Voy a configurar el almacenamiento local, todos los datos, luego realizaré la prueba relacionada con mi página en particular. Y si algo está mal, como durante la marcación de los datos, simplemente puedo evitar hacer la prueba y redirigir a la página predeterminada. Para probar diferentes versiones de una funcionalidad en una página, aprovechamos las cookies del navegador. Creamos un servicio de utilidad que cambia los valores del servicio de banderas de funcionalidad y los fusiona con nuevos valores. Después de configurar la clave dentro de una cookie, escribimos la prueba. Aunque tenemos buenas prácticas implementadas, siempre hay margen de mejora. Planeamos alejarnos del trabajo programado y agregar pruebas de extremo a extremo a un pipeline de CICD. También consolidaremos las pruebas de extremo a extremo en nuestro monorepo para el micro frontend. Únete a nosotros en Delivery Hero.

marcado aquí. Y lo que haré después de esto, usaré la ventana sin marcos. Configuraré el almacenamiento local, todos los datos, luego realizaré la prueba relacionada con mi página en particular. Y si algo está mal, como algo está mal durante la marcación de los datos, puedo simplemente evitar hacer la prueba y puedo redirigir a la página predeterminada. Ahora, lo que viene a continuación es, ¿cómo estamos probando realmente las diferentes versiones de una funcionalidad? Supongamos que estás en una página, tienes tu página, pero ahora quieres probar diferentes versiones de tu funcionalidad en esa página en particular. Entonces, ¿qué harías? Para esto, encontramos una solución simple, aprovechar las cookies del navegador. Creamos un servicio de utilidad en nuestra aplicación que utiliza las cookies del navegador y cambia los valores que provienen del servicio de banderas de funcionalidad y los fusiona con los nuevos valores. En este caso, este servicio de utilidad se puede utilizar para cambiar la variación de la bandera de funcionalidad y se ve así. En este caso, puedes ver que tenemos las banderas de funcionalidad que provienen del servicio, tenemos las banderas de las cookies, las fusionamos y las almacenamos en la memoria caché. ¿Y qué sucede después de eso? Ok. Nuestra aplicación está lista para manejar las cookies. Ahora solo necesitamos configurar esta clave en particular dentro de una cookie con las variaciones mencionadas aquí. Como puedes ver en la prueba, prueba para la variación de la bandera de funcionalidad, simplemente configuro la cookie para esas variaciones y luego, después de eso, puedo seguir escribiendo mi prueba. Como puedes ver, tenemos muchas buenas prácticas y tenemos cosas buenas implementadas en este momento, pero nadie es perfecto y siempre hay margen de mejora. Entonces, algunas cosas que notamos y tenemos un plan para ello. Una cosa es alejarnos del trabajo programado y agregar pruebas de extremo a extremo a un pipeline de CICD. Y lo siguiente es, como mencionó Vadim, tenemos las pruebas de extremo a extremo en un repositorio separado. Y tuvimos el caso de uso porque estamos migrando del monolito a un micro frontend. Una vez que todo se haya migrado al micro frontend, agregaremos las pruebas de extremo a extremo a nuestro monorepo para el micro frontend y definitivamente seguiremos mejorando. Eso es lo que estamos haciendo. Seguiremos mejorando la calidad de nuestras pruebas. Y por último pero no menos importante, por favor, únete a nosotros. Estamos buscando desarrolladores como tú, por favor únete a nosotros en Delivery Hero. Gracias. 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

TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

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.
React Advanced Conference 2022React Advanced Conference 2022
22 min
Monolith to Micro-Frontends
Top Content
Many companies worldwide are considering adopting Micro-Frontends to improve business agility and scale, however, there are many unknowns when it comes to what the migration path looks like in practice. In this talk, I will discuss the steps required to successfully migrate a monolithic React Application into a more modular decoupled frontend architecture.
React Advanced Conference 2023React Advanced Conference 2023
22 min
Power Fixing React Performance Woes
Next.js and other wrapping React frameworks provide great power in building larger applications. But with great power comes great performance responsibility - and if you don’t pay attention, it’s easy to add multiple seconds of loading penalty on all of your pages. Eek! Let’s walk through a case study of how a few hours of performance debugging improved both load and parse times for the Centered app by several hundred percent each. We’ll learn not just why those performance problems happen, but how to diagnose and fix them. Hooray, performance! ⚡️

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 Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Building a Shopify App with React & Node
Top Content
WorkshopFree
Shopify merchants have a diverse set of needs, and developers have a unique opportunity to meet those needs building apps. Building an app can be tough work but Shopify has created a set of tools and resources to help you build out a seamless app experience as quickly as possible. Get hands on experience building an embedded Shopify app using the Shopify App CLI, Polaris and Shopify App Bridge.We’ll show you how to create an app that accesses information from a development store and can run in your local environment.
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.
JSNation 2022JSNation 2022
41 min
Build a chat room with Appwrite and React
WorkshopFree
API's/Backends are difficult and we need websockets. You will be using VS Code as your editor, Parcel.js, Chakra-ui, React, React Icons, and Appwrite. By the end of this workshop, you will have the knowledge to build a real-time app using Appwrite and zero API development. Follow along and you'll have an awesome chat app to show off!
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Hard GraphQL Problems at Shopify
WorkshopFree
At Shopify scale, we solve some pretty hard problems. In this workshop, five different speakers will outline some of the challenges we’ve faced, and how we’ve overcome them.

Table of contents:
1 - The infamous "N+1" problem: Jonathan Baker - Let's talk about what it is, why it is a problem, and how Shopify handles it at scale across several GraphQL APIs.
2 - Contextualizing GraphQL APIs: Alex Ackerman - How and why we decided to use directives. I’ll share what directives are, which directives are available out of the box, and how to create custom directives.
3 - Faster GraphQL queries for mobile clients: Theo Ben Hassen - As your mobile app grows, so will your GraphQL queries. In this talk, I will go over diverse strategies to make your queries faster and more effective.
4 - Building tomorrow’s product today: Greg MacWilliam - How Shopify adopts future features in today’s code.
5 - Managing large APIs effectively: Rebecca Friedman - We have thousands of developers at Shopify. Let’s take a look at how we’re ensuring the quality and consistency of our GraphQL APIs with so many contributors.
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.