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 tests 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 start doing that, the end-to-end test setup, and the best practices we use, how to avoid repeating the cycle while developing tests, and how we are testing different variations of the feature. So the case study for the end-to-end tests 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 tests, so we don't need to do manual 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 old monolith has 200k total lines of code. So it's quite big. The end-to-end test setup we have is basically a separate repo, because we added the tests while we were migrating from the old project to the mono repo with the micro front-end, and we have the simplicity of running the tests in the separate repo, so we can easily onboard developers. For now, we run them as a cron job. We know that it's not a standard, let's say, but we are working on the integration to the CI-CD pipelines, and we created our own custom Slack integration with Cypress. We know that there is an official plugin developed last week, but we still have our own for now. You can see the example of what the Slack bot is messaging with the report, and you can click on the report button and check this kind of a report, which is very helpful, because it shows 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 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 Dabesh. Please. Thank you, Vadim. Hi, everyone. So, Vadim, you told quite a good scenario, like what are the best practices we are following, and so I'll be guiding you through about two particular things that we are doing at our end, which really helps us achieve E2E test very quickly. This one particular thing is about how to avoid repeating the cycle. Most of the E2Es that you see nowadays, it's like a single flow. First, the E2E goes to the one page, then the second page, then the third page. It's a sequential manner. But considering we are the 20 plus dev team, as Vadim mentioned, and different teams are working on different pages or different modules, we don't want to actually repeat the whole cycle during the development. We want to test our features, we want to test only our page. So this will be something like this, going from one page to the other page. So how are we actually achieving it? So we actually created a utility service in our utilities, I mean, not the utility service, but you can say a command that Vadim mentioned, we have a custom command, which is about go directly to the page. So what happens in this particular command? So this could be any page, like this could be a go directly to my page, and then I can actually mock 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 mocked here. And what I'll be doing after this, so I'll be using the like, C++ 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 mocking of the data, I can just avoid doing the test. And I can just redirect to the default page. Now, so what comes next is like, how are we actually testing the different versions of a feature? So suppose you are on a page, so you have reached your page, but now you want to test different variations of your feature on that particular page. So what would you do? So for this particular thing, we went to a simple solution, like use the 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, 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 the 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 room for improvement. So a few things that we noticed, and we have a plan for it. So one thing is like moving away from the Cron job and adding the E2E test to a CI-CD test. And the next thing is like, as Vadim 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 frontend. So once everything will be migrated to micro frontend, we will be adding the E2E to our monorepo for the micro frontend. 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 least, please, please join us. We are looking for some developers like you. Please join us at Delivery Hero. Thank you. Thank you.