Adaptation of the E2E Tests for a Big Project

Rate this content

DeliveryHero is a huge international company. And like in every big company, the introduction of a new technical improvement is a hot topic. Get to know the challenges our team faced while making our platform E2E tested, how our reporting mechanisms improved over time and solutions we developed to test different variations of a feature.

8 min
18 Jun, 2021

AI Generated Video Summary

This Talk introduces the adaptation of end-to-end testing for a project, highlighting its benefits in improving resilience and calmness during deployment. The speaker mentions the team's size, daily pull requests, and the size of their codebase. They also discuss the use of cookies to test different versions of a feature on a page and their plan to improve by adding E2E tests to a CICD pipeline and consolidating tests in their monorepo.

1. Introduction to End-to-End Testing and Setup

Short description:

Hi, I'm Vadim, a front-end engineer from Delivery Hero, and today with my colleague Devesh, I want to present you the adaptation of the end-to-end test we have done for our project. We thought it's a big improvement to introduce the end-to-end test to improve our resilience and calmness while deploying a big change. We have more than 20 front-end developers, do 10 pull requests daily, and our micro-front-end repo has more than 50k total lines of code without node modules. The end-to-end setup is a separate repo, and we run them as a cron job. We also use best practices from Cypress team and accessibility principles in the test. Now, I want to give over to Dinesh.

Hi, I'm Vadim, I'm a front-end engineer from Delivery Hero, and today with my colleague Devesh, I want to present you the adaptation of the end-to-end test which we have done for our project in Delivery Hero. The agenda for today would be the case study for the end-to-end tests, or why we are start doing that, the end-to-end test setup, and the best practices we use, then how to avoid repeating this cycle while developing tests, and how we are testing different variations of the feature.

So the case study for the end-to-end were pretty simple and common like for everyone, because Delivery Hero is a huge company with a huge front-end project, it takes a lot of time and effort to maintain and develop it, so we thought that it's a big improvement to the situation to introduce the end-to-end test so we don't need to do manually testing features every time or debug fixes, so we can improve our resilience and the calmness while deploying a big change. So just to have an overview of the scale, we have more than 20 front-end developers, we do the 10 pull requests daily, our micro-front-end repo has more than 50k total lines of code without node modules, and the monolith have the old monolith have the 200k total lines of code, so it's quite big.

The end-to-end setup we have is basically a separate repo, because we added the tests while we are migrating from the old project to the mono-repo with the micro-front-ends, and we have like simplicity of running the test in the separate repo so we can easily onboard developers. For now, we run them as a cron job, yeah, we know that it's not a standard, let's say, but we are working on the integration to the CICD pipelines, and we created our own custom Slack integration with Cypress. We know that there is an official plugin developed last week, but yeah, we still have our own for now. Yeah, you can see the example of what the Slack bot is a message with the report, and you can click on the report button and check this kind of report, which is very helpful because it shows like the stack trace, the error, exactly error, and the screenshot. We also, of course, are using some best practices from the Cypress team and some of our own, which is trying to use accessibility principles in the test created by Ken Dodds, which is the testing library creator. So instead of using data CI, which is a best practice from Cypress team, we can use the area labels and other accessibility attributes, which is very helpful and handy. We also, of course, use the Cypress commands for general helpers, like if something is used in separate specs, or more than two times, we just wrap it into the command and use it as a one-liner, which is simpler. As well, we are using like a given annotation, but not only as a structure for the test, but also, as a command, because as you see here in an example, it's very helpful, because even if you remove the whole code, you still have an idea of what the test is going to test, because sometimes the commands can be complicated.

And now, I want to give over for Dinesh, please. Thank you, Vadim. Hi, everyone. So, Vadim like told quite good scenarios like what are the best practices we are following. So, I'll be going like guiding you through about two particular things that we are doing at our end, like which really helps us achieve a test very quickly. So, this one particular thing is about like how to avoid repeating the cycle. So, I mean, most of the E2Es that you see nowadays it's like a single flow. First, the user I mean, first the E2E goes through the one page, then the second place, and the third place. So, it's a sequential manner. But considering we are the 20 plus dev team, as Vadym mentioned, and like different teams are working on different pages or different modules, we don't want to actually repeat the whole cycle during the development. Like, we want to test our features, we want to test only our only our page. So, this will be something like this, okay? Going from one page to the directly to our page. So, how are we actually achieving it? So, we actually created a utility service in our utilities. I mean, not the utility, but you can say a command that Vadym mentioned. We have custom command, which is about go to the page. So, what happens in this particular command? So, this this could be any page. Like, this could be a go to my page and then I can actually mark the previous data about all the pages which came before it, like all the data that they added to the browser, to the storage, everything will be marked here. And what I'll be doing after this, so I'll be using the, like, SIPLESS window.

2. Testing Different Versions of a Feature

Short description:

I'll be setting the local storage, all the data, then I'll perform the test related to my particular page. And if something is wrong, like during the marking of the data, I can just avoid doing the test and redirect to the default page. To test different versions of a feature on a page, we leverage cookies from the browser. We created a utility service that changes the values from the feature flag service and merges them with new values. After setting the key inside a cookie, we write the test. While we have good practices in place, there's always room for improvement. We plan to move away from the cron job and add E2E tests to a CICD pipeline. We will also consolidate the E2E tests in our monorepo for the micro front end. Join us at Delivery Hero.

I'll be setting the local storage, all the data, then I'll perform the test related to my particular page. And if something is wrong, like something is wrong during the marking of the data, I can just avoid doing the test and I can just redirect to the default page.

Now, what comes next is like, how are we actually testing the different versions of a feature. Suppose you are on a page, so you have your page, but now you want to test different versions of your feature on that particular page. So, what would you do? So, for this particular thing, we went to a simple solution, like, leverage the cookies from the browser. So, for that, we actually created a utility service in our app, which uses the cookies from the browser, and it actually changes the values, which are coming from the feature flag service, and it actually maps to, it merges with the new values. So, in this case, this utility service can be used to change the variation of the feature flag, and it looks something like this. So, in this case, you can see, like, we have the feature flags coming from the service, we have the flags from the cookies, we merge it, and we store it in memory cache.

And what happens after that? Okay. Our app is ready to handle it, handle the cookies. Now, we just need to actually set this particular key inside a cookie with the variations mentioned over here. So, as you can see in the test, so, test for feature flag variation, and I'll just set the cookie for those variations, and then, after that, I can just keep on writing my test. And so, as you see, like, we have a lot of good practices, and we have good things in place right now, but nobody's perfect, and there's always a room for improvement. So, a few things that we notice, and we have a plan for it. So, one thing is, like, moving away from the cron job and adding the E2E tests to a CICD pipeline. And the next thing is, like, as Vade mentioned, we have the E2E test in a separate repo. And we had the use case, because we have two different projects we are supporting. We are migrating from the monolith to a micro front end. So, once everything will be migrated to micro front end, we will be adding the E2E to our monorepo for the micro front end, and definitely, always keep improving. So, that's what we are doing. We'll keep improving the quality of our test. And last but not my least, please, please join us. We are looking for some developers like you, please join us at delivery hero. Thank you.

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
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
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
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
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
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
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
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
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
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.