Adaptation of the E2E Tests for a Big Project

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.

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.