How to automate tests with Cypress and TestRail

Hello, everyone, welcome to yet another Buddy webinar. Today we are going to talk about how to automate tests using Cypress. And TestRail. And to help me I have Christian Dangl with me our favourite returning guest. I hope it's, I mean, this is your second time here, but I really hope it's not the last one. So, Christian, tell us a bit about yourself because some of the people in the audience don't know you yet.

Of course. Hello, everyone. I'm glad to be back. Thanks for having me one more time. So my name is Christian Dangl and I work at ecommerce company does this map in Munich or near Munich in Germany, and we create b2b online shops, b2c online shops, enterprise for enterprise customers based on 100% shopper. And in general, I work quite a lot with development, DevOps, and of course, QA and I do trust a lot. And yeah, I'm here to show you something hopefully very cool today.

All I can say is very cool. That's very cool. And my name is Maciek Palmowski. I work here at Buddy as a WordPress ambassador, and I'm your favourite and only webinar host. So before we start, let's see what we learned today. So we'll learn a bit about TestRail, learn how to create a project, how to use it, we'll learn how to automate testing using Cypress. And we'll see how to create the Buddy pipeline that will prepare the whole environment and run all all the tests. Also, if you have any questions regarding the topic, don't hesitate and ask in the comment section either on YouTube or LinkedIn, it depends where you are watching us. So I think that's Oh, and of course, if you like the things we are doing here, don't forget to press that subscribe button on YouTube, we will be very glad and you will be informed about all the new things that are coming and happen on our channel. Okay, so without any further ado, because I know that Christian prepared a lot of information for us. Oh, yes, he's so Christian. The scene is yours.

Thank you so much. All right. So if you could share my screen, then I would love to show you simple course. So this talk is all about testing. So how to automate tests with Cypress and test will and Buddy and chapter six because we mix up everything. So in a nutshell, this is about an evolving QA process that you usually face during a project. So I will show you in a super fast way, of course, how to go from manual testing to a structured test, case driven testing, and then on to automation, bring Cypress into play, and also automate the reporting and running of the Cypress tests. So everything that brings you forward in your project. But before I start, let me really introduce myself I almost said the whole stuff here before so my name is Christian Daniel, and I'm working as Head of Technology at the shopper agency does this map in Germany. So as already mentioned, we create for our enterprise customers, shops ecommerce system based on shopper in addition to this, I run my own company, which is Livescore, a scoreboard graphic software that is used by NHL teams for MLB. ATP 10 is in way more across the world. So these are the companies and besides that I'm also involved in lots of open source projects, such as SVR unit that is a unit testing framework for service. So you can automate testing servers, Docker containers, Docker images. And speaking of Docker, I'm also involved in the Docker i o project that is in the shopper, sector and industry, a huge project to speed up development environments and just get going with shopper. So as you can imagine, I'm doing quite a lot and know a couple of programming languages such as PHP, C sharps, with Java and more. And do a lot in DevOps. And the fun thing QA, obviously, because if you do a lot, you know that you have to test it out. Otherwise, you might have a problem on a Sunday morning, you know it. So are Friday evening, it's worth Oh, Friday evening. It's where. So first of all, thank you for Buddy. So they are hosting me today. So I can tell you something that you might find useful in your project, and should help you in the future. So we are going to use Buddy later on. But in a nutshell, it's an amazing CI/CD system. It looks fancy. And it helps us to get going in a very easy way speaking of QA processes, and also rollouts and deployments.

So our actual goals for today, I have prepared a shopper six plugin. So we are going to manually test the plugin as you will probably start with your project, then we become kind of confused. So we tend to ask ourselves, do we need test cases specifications acceptance criteria we had on to test rail and get a structured project setup. After why we bought so yeah, let's automate tests, why not? And then we somehow got frustrated. So let's automate reporting the results of these automated tests. And, in the end, totally nuts. Let's automate running the automatic reporting of results of these automated tests. So that is where we are in, hopefully under an hour. So the repository after day, I'll give you a few seconds, if you want to scan it, the link is below it. Otherwise, Maciek will probably add it to the YouTube recording later on, you can just clone it. It has very easy installation, but for now, I would ask you to just keep on watching. So let's start. Let me show you what I've prepared for you. We have a shopper six Demo shop in here. So that is locally on a used with Docker. And in the administration, I just login. We have a prepared extension a plugin installed, which is a Notification Centre. And that Notification Centre helps us to output a text. So for instance, super discounts. Just for today, we can modify background Colour, Text Colour, if we go to the storefront. That's just a notification text. We are now going to test that one. So I did already.

Addy, kind of a test. So I used to, but what if we now? Keep it active and remove to text? So will the blue area will still be available? Hopefully not. Otherwise, that might be a bug. What if we change background colour? Is it really red? Yes, it is. Do we have the option if we have like a more lighter background colour the option to also change the Text Colour otherwise you probably can't see it. So it has to be darker. So that is validation? Can we actually use the product? Yes, we can. So this is all manual testing. It is just a small plugin. But if it gets more complex, there's plenty of stuff you really have to test. But we have no instructions. That is just kind of exploratory testing going through it and yeah. Approved you can release it to 1000s of customers. That is probably something that works but not for a long time. So this is why in most cases we want you to be more professional and more structured. So we are now going to the process of having concepts, meaning we have acceptance criteria. We have it Instructions, how should we work? What should actually be done, we verify those concepts, those criteria. And then we build test cases. Test Cases are basically just step by step instructions. So click here, click there, this should be visible, you know it. You could use any software, Microsoft Word, Apple Pages, just actual problem is in testing. One of the most important thing is a traceability as well as reporting. So where to store the results, data work, how to report things. Word pages, actually might not be the perfect thing, though, it might suit your needs sometimes.

So this is why test management software exists. As already implied by the name, it helps you to manage your test cases to report the results. And one of those applications is test rail. I'm using it a lot, we use it a lot in our company, because it has a totally awesome look and feel that helps you to be really efficient. So it's not that huge, fancy stuff. So if you go to task rail, you usually create your first project project. So it's a Buddy webinar. In my case, it project consists of different tabs. So there's an overview. There's a to do list, if you call it collaborate with multiple testers, for instance, you can add milestones, if you have milestones in your project, test runs, the actual runs that we test with the results, test cases, and reports. So test cases is the most important thing. It's basically the catalogue of all your tests. It's the main thing. And this is where we start by figuring out what tests do we actually have. So Maciek, now that you know the plugin, would you can you think of anything that we should test?

Yes, we haven't you already mentioned few cases. So we should try to first of all, try to log in inside of the shopper.

Administration.

Exactly. And then, first of all, check what will happen if we fill out that tags we can check is the Active button is working, we can also check something about the empty field because this was very interesting edge case you mentioned. And the thing about testing is colours of text and background are as they should be.

So we have stuff

quite a lot. And it's such a simple plugin and out of top of my head, I don't know, five or six.

We have Should I show you how to create the new test case in test rail, of course. Okay, so we are in the test case, cases page. And there's a add test case, I could either use that one or just that's cool thing, use some inline adding. So we probably start with the happy path, enter, activate and enter text and text should be visible in storefront as we work in progress title, so when you add a test in test rail, there's a detail page that helps you to add way more than just a title and instructions. So usually you have a good speaking not too in my case not too long on test title. So that might not be the perfect one but it helps you to to differentiate between those tests later on. There are different templates you can set up exploratory sessions with missions and goals. You can have simple text instructions or even step instructions. As already mentioned, test cases are just well prepared instructions. That means our precondition might be plugin is installed and activated in sharper and we add a step. The step might be open plug in configuration, expected result is configuration visible. It's not a perfect way how I do it, but I just want you to get familiar and become familiar with that one. Then activate or toggle the active to on Toggle is on. Then let's do enter a valid text valid, it can't match it. So enter, text discount available. And then text is visible. Then click on Safe, safe, modal alert is visible. And then open. Open the storefront, you should see the notification above the main top navigation bar. Save it. So

yes, this is the cool part about live webinars things like this happen. I can say that.

Yes, so test cases. Oh,

okay. It's there. Okay.

Do you think it's okay,

I had to once they have, I think a lot of people use it, they have a huge high availability setup, and seems like one app instance, might have a problem test. Well, if you're watching, it's your turn up. Anyway, so it was still safe, which is a good thing. And as you can see, the basic thing is about those different steps. So usually I would combine if you don't have it that much detail, because the more instructions you have, the more time it takes to read it. And just imagine someone else testing it for you if you're outsourcing to a test, crowd testing or something like that. So but in general, you get the idea. So we have steps.

So as I understand, such an instruction should go like a person that doesn't have a clue about your system, we'll just go step by step, and we'll be able to fully understand what he's doing or she and see what the result should happen. So like and everyone

could do and, and that combined with a reduced text, if possible. So not a long one. Because the problem is, if you have to test a lot of tests, you just end up reading, reading, reading, the more you read, the less you understand, too much work overloaded. So keep it simple. Keep it as much as in detail as possible. But always think about efficiency. So that is indeed, as we as developers, when it comes to building a good architecture that is really an in an effort to build good tests, good, readable and functional tests, or descriptors test case. So but I think you get the idea. So then we have the option to add a type for our tests. Why do we need this, if we just go back to our test cases, we have like hundreds of tests. For instance, we want to be able to filter those tests and really test what we need for release. We have different options. One option is to have sections, let's just create a few tests. So activated that storefront should not show test, text if text empty. We have change, check. But let's change background colour of text and change text colour of your text. We have the option to add sections. So like colours and general. And now you know why I just love the way how the UI and look and feel is being developed. It's just something you really can use in an efficient way. So one thing is to use sections to structuring your tests and then in E commerce system, you would have Checkout account whatever. Another way to filter these things is to use a type. So we activate and enter that is our most important test. So that's why we use it as smoking sanity. test. So a smoke and sanity tests, only a handful of these tests should in theory exist in your application means if these tests do not pass, it doesn't really there's no need to test further probably because the soul of your application is already completely destroyed and not working a lot, probably. So.

In other words, it's important. There's also the option to have regression tests, functional tests, performance tests, you can categorise the that those and use it later, then we have priority. Okay, you can use five minutes for that a test. So when we plan test runs, we get estimation reports and how much time to cover, then we can use references that this could be either acceptance criteria for traceability, or even your Ciara ID if you have Ciara connected to it. And then you even get tooltips pop ups of your, let's say, epic, and it instructions and texts, pretty cool thing. And automation type. Yeah, none, Cypress, you can do whatever you need. If I now save it, you can see that I have kind of plenty of tests, I do have different criteria, type smoke, the other ones would be other or regression. And I can use that. Now when building a test run. Just one thing that I would love to tell you need to tell you, we have huge projects, we have, let's say 800 tests or something like that. So that is cool. But you can't really test it if you are not lots of people working as testers. So the good as if you know, unit test, PHP unit, or chest or any unit tests, any programming languages, the cool thing is it runs in milliseconds. So super fast. That's why we can and should test let's say every property in a separate tests, it's about reporting again. So by by eyes, you immediately know what property is red. And now that something is red, that is only possible because it runs so fast. So one test should be one assertion. If we go to and to antastic, like this, testing takes a while, because websites take a while the whole process of such a test plugin configuration takes a while. So we faced a problem that it was just not possible to test it over everything again. So one idea would be try to structure your tests in some kind of real end to end scenario where you implicitly implicitly test different things in one single case run, then you can avoid having separate tests where you have to start from scratch, just to test an edge case, for instance. So now that you saw how to create tests, how to what to consider when building tests, you can imagine having profession really, really rock solid test cases, is really hard work. And not only hard work, but a lot of lots of experience. And that's why testers or test managers are really super important, and not just testers. Now to the dummy part, we just test just test what people would think of testers. So when you create a test plan, release, you might create a test plan, like plug in 1.02. In such a test plan, you can add test runs, I just show you what I do usually do. I create a smoke and sanity test run, then I use dynamic filters. That brings me up the whole picker of all test cases. Now you know why sections are important. But what I do is I just use the type filter, you smoke and sanity set the selection. Click OK. And save it then I if I would add a another smoke and sanity test that would appear here. Then I add in addition, test run maybe new features and regression. And then I manually pick what I would need speaking of traceability to test with that specific release of my plugin, but that is not enough. Touch will offers more. You can even create configurations and build custom groups and configuration options. In my case, I've crazy group browser and operating systems. So let's say I test on a Mac with Chrome and Safari. Right, click OK. Save my test plan. As you can see, I ended up having two separate test runs for my new features and regression, one for Chrome, one for suffering from Chrome, Mac, and Safari Mac. And I could then assign different tests as to it. So there's really plenty of stuff that you can do.

What if we now test so as metrics are told us, we should add a text, save. And that's it. If I start to process, I usually start with the smoke and sanity test before I do anything else. So this is the overview of all tasks in that test drum, I do have my step by step instructions. And once I know the results I just open past for instance, I could start and stop right now. And then I could either say it worked, it failed, I would need to retest, I could even do that on a level of those steps. So that the developer really knows step one, two successful Step Three failed. So pretty, pretty cool. I could also provide version and defect, one of the coolest things I can't show you right now, because I have a couple of demo. Projects, obviously, and accounts which are removed later on and an additional Atlassian demo account, you know, but usually, you create a defect. And that defect is then pushed to your charter board, as a ticket can be developed by any of the engineers. And every test run every test plan has a live overview of existing defects. So your QA testers could just go into that either smoke and sanity or plugin release package. And check out if any defects are still existing and what their gyro status is. Is it in progress? Is it done? So they know without leaving Tesla, what is going on? And that is just amazing. So enough compliments to testrail, let's just add a pest because it did work. Yeah, that's how it looks looks like down there, we have a passed or failed reason results. So I could add more and more as time passes. Once done, I just close my whole test plan or test run, and then everything can be rolled out or is already rolled out. So now we know how to structure tests, the work behind it, and how to actually build and PLAN test plans and test runs and provide feedback on these one thing that I totally forgot. Now that I see it is the chart. It's all about reporting. So your project manager might ask, Hey, can we finally release our new super awesome plugin, and you can immediately say, hey, we have only one of five tested 0% is past might not be good enough to to release it, give us more time or fix it in the meantime. So that is just with clip seven are you have immediately every report and in addition to this, there's a report section where you can generate those reports. But that is too much for now.

So now, as promised, we are kind of bored, we have to repeat that step over and over again now that we're not confused anymore. So this is why we want to automate things. And this is where we use Cypress if you don't know Cypress let me just show you with that prepared project we have a list of files so GS files and there's one config and if I open it HS test text can be displayed in storefront it's empty we are going to fill it right now. But as you can see, it already does something so it's working pretty good. If we now go to our source code, so as I already mentioned that is open source you have total access and full access to it just open so this is all sharper. There's a custom plugins folder with our Notification Centre plugin. And inside there are talking instructions to run it and test test consists of a an additional folder Cypress that has a makefile just used to make instal make Oh Open UI or make run. So if I just show you I could do make Open UI

with my localhost or a remote host. So you can actually test your testing system from local Cypress installation, or just use to make run, which is the same only on a CLI level test rail already finds an error because it's configured. But as you can see, it's the same. And this is what we use in a CI/CD system, such as with Buddy later on. But now let's just open the UI one more time. And yeah, actually create a test. So what we usually do is, we have our Cypress test cases, and our tester one day says, Okay, we have some flaky stays, this is working again, it's not working the other day, or this is just too much to test over and over again, could you please automate test number, c nine. So test real has C prefixed IDs for test cases, unique identifiers. So our goal is now to automate this test as good as possible. So usually, there's a kickoff between a tester as well as the developer, the developer who should implement it, and then they just go through it explanations, just some showcases, and then testing or implementation of the script happens. So if we open, I assume, you know, Cypress a bit, otherwise, just be amazed. So that's enough. I do have a prepared empty test in here, just ignore that above. Usually, you will just use the playground for instance. And ups, just click on that thing, copy it. So that grabs our element using selectors, and then we click on it. So we clicked on it, we click on the login button one more time. Oops. And then we should end up on the log login page. So that is how you usually can create Cypress tests, or at least get started. Problem is, you end up with lots of bad stuff mean, hopefully lots of tests. So pain in the ass if you just have to switch a centralised login functionality that is used across all these tests. So I did prepare some page objects actions. So I do have separate separate webinars and things on that. But it's it speaks for itself. So we start by using the admin login action, and we just log in into the administration. So just to give you an idea, it opens slash admin, and just fills in the default credentials and clicks on submit. So that is how everything is built in the background. Then we use a plug in action that I've initialised above. And I opened the plug in configuration. And we want to activate with true false. Oh, I'm Peter. We want to say hey, set text Normally I would use the text from the test case, but I want to show you Cyprus was here. And then we use plug in safe settings, then I Yes. If good people aren't here and usually he don't do this No wait, but in that code we just wait for for for cash being pruned a second that's totally fine for now. And then we visit slash page and we've CI contains we assume that verify that Cyprus was here is found. And in theory theory that is not a perfect thing. So I do have a Rei pro storefront that basically just gives me that fifth layer. And I could also check if be pumped visible if that layer is also visible. Yes, usually you would also match if that text is really in that layer, but I think you get the idea. If and I rerun it you see that just be amazed. It logs in into the administration opens the plug in configuration enters the tax clicks activate click on save, and then opens oops Yeah, yes. And suddenly something is not working again. So looks like I have called on. Mods. Yeah. Because there

is because there is a new

version. Yeah, that new sharper version? Come on. Really? Yeah, just today. But yeah, things happen. So I just use that. Safe settings, click multiple and we just hope it works. Any shopper today before my webinar?

How could they not it? No, it worked? Yes. No, it worked because it redirected to the update.

Okay. Then just do this one click on safe

contains save, click this Yes. Okay, safe is also fine. So yeah, things happened during a live presentation. I still love doing it live. So as you can see, I'm glad it worked. And we ended up in the storefront and everything was validated. So that is how you usually build Cypress tests. So if I now copy my backup you should see don't really have it's working but it should. But now we have way more tests we have tax can be displayed in storefront we have no notification is if config is disabled. And we also have background colons text colour can be adjusted. If we just check out that x tests, you even see that I set a hex hex colour base background colour, a text colour and verify the CSS entries later on in the storefront. So plenty of stuff that you can do with Cypress. So back to our story, we have test where we have our test run.

And problem is we have to manage the start Cypress locally and then add our results in here might be a bit annoying. What we usually do is this, as soon as a test is approved, we do have an integration. So let me just show you get up. It's all open source. And I'm not the only one having so there's a club well Maya people you just know from the Cypress community. And they have also done such integration just dating myself needed a bit bit in a different way than extended it. And it's just fun. I just love doing things. So you instal instal, in that case, Cypress tester integration NPM based, you have a configuration with your credentials of testrail. And then there's two ways either add results to existing tests, or create a new test run test runs existing tests where all new tests run, easy configuration and most important part, you just add that C identifier. So let me show you first thing, in order to have it working in the Andis, industrial customer site settings, activate the API. Very important, then we all we need to do after setting up our stuff is I will not show you the Cypress and for JSON because it contains my credentials. But it's existing. And all I have to do is our C nine test test is now this one. So C nine. That's it when running our Cypress test now in the test rate integration mode, I have to provide in that case a test run. So what I usually do in here is I add a different most of the time as first one so that it's on top, but we can also think it's Cypress test. So top bottom

is I let Cypress test everything for me once it's green. I will manually test smoke tests and once they are green, I will test the new features and regression tests. So Cypress test means I will Now, just save this one, otherwise empty runs cannot be saved. So once something is automated, I do open it in here, have an approval by our, as a developer have it been approved by my test manager or someone from QA. And then they said it to be automated in that case by Cypress. That means it's an additional thing that we can filter for, which we are going to do now. So our Cypress tests contain with a dynamic filter, everything that is marked as Cypress, while our smoke tests do now contain everything, I mean, I do it in that way that is not Cypress automated, and still smoke and sanity. So that is really something you have to decide if you want to double check your smoke and sanity tests or not. But that's it, I can save empty test run. So I just add any of those. And save. And now it's time to start everything. So I have my Cypress test, and I do have an R 18 ID. So either in your dot n, or as an environment variable, I'm use this one because I'm not going to show you the other one. It just we had 18 and then make run your URL is HTTP, localhost. And then we are running already with this test rail integration mode. We have some major data, what Cypress version? Do we have a browser we're using? What local URL are we testing against? What domain are we using, we use an existing run, and that is 18. And once those tests are done, it sends the one that is recognised inside that test run to test real. So if I now just refresh, it is green. And it has a past entry with the made of data what spec file, you could even add shopper version. So I have with sharper plugins, multiple sharper versions being used at the same time. So I really know what sharper version might be screwed up what works. And so lots of data you can use. So this is one option. The other option is something I will show you in Buddy. It's the second mode where test runs are created dynamically. So in my case, I want to have everything green to release it. If you have like a really big bigger project, traceability and stuff like that. So every test run is usually close after it's run, so you know what happens. And then you can trace it, if it failed, if it failed, if it worked if it worked, and pass Sunday. So there's a second mode to dynamically create test runs. But first, as promised in the introduction, slide, we are now in the nuts area where we want to automate that automatic reporting to automatically run tests in how many automatics I don't know, this is where Buddy comes into play. So with Buddy, if you're not familiar to Buddy, then you also have projects there. Those projects are usually your usually your Git clone repository. So I did already create one. And this is connected to my GitHub repository. But you can also have some standalone GitHub repos there. And then you build pipelines. So this is what we are going to do we build a new CI CD pipeline, we can have it being triggered manually or automatically. Let's do this manually, automatically. And then we have the option to select across hundreds 1000s of actions. For PHP, Linux virtual machine, SSH, local SSH, local shell CloudFlare, integration stalker stuff, a lot. If nothing works, there's a pretty cool one that I'm a huge fan of custom built, because it's all driven by Docker. And I am now just going to use the

Docker flex. This is a project that we have and then I just reset the default image entry point route. So that is described on a page that I can show you later on. And then all I do is I make instal wondering if I have to go into a folder but I don't think so. So let's say instal dependencies, dependencies. And before I talk too much, let's just run it. And it should now

finish Yeah, perfect. So what it does is, we have a make file in here that just does the MP in route, a composer installation for our PHP vendors in the plugin. Once run, I can even use the Browse file system and see that okay, fine, we have purple created vendor folder. So that seems to be good. So next thing is we are going to instal Cypress because it also has to be installed obviously, I will because a requires NPM and other stuff, but a cypress prepared action that would even run Cypress but let's just do this one. So I go to the folder tests slash Cypress and do a make instal same as locally. And then we instal Cypress. So while it runs, the reason why I'm always doing make abstract make files is I use it as an abstraction layer because every project that I at least do or own is working pretty easy, not only in CI/CD systems, but also locally. I want developers to use Cypress locally without thinking how to get it running. So that is very important for me and also abstraction layers such as make us happier to have your CI/CD systems in a stable way. Just one day I'll make instal might also you have some NPM packages and not only composer stuff. You wouldn't need to change your CI CD pipelines or Tahlia developers to Hey, after composer instal please also empty NPM installed, just have one make instal. And whatever is behind it is just being executed. So the other

thing that's similar tactic would be to use either composer scripts or NPM scripts, something like this. But abstraction layer is a great way because always one command will do the same thing. And you don't have to wonder what is behind it.

Exactly. So now we have a purple folder node modules, which means it did work. So now why did I do it in that way just instal Cypress, you could also just run Cypress, but I want to have you could decide with with my approach of providing the base URL, just have Buddy test your staging environment. And that's just whitelist, the domain IP whitelist Buddy and everything good. But I want to go one step further. I want to locally test my whole plugin in a sharper version directly on Buddy before it leaves the system before deployment or whatever is going on. So for that approach, I use the same as I did locally. So we have a project called Docker, at least for for shopper. That's, in a nutshell, some amazing dev environments for shopper, you can easily use any shopper version and just have it up and running in download time and then just five seconds is up and running. So there is plenty of docs. Doc pages available. In our CI/CD section there's Buddy and if you're missing something just let us know and we'll add it but there you can find what I just showed you. And down in the Cypress test. It shows you how to use Docker in in that case, Buddy for Cypress or whatever you are trying to do instal the plugin. So we use a Docker CLI action that allows us to

have some doing the same thing as locally we have an Ubuntu environment with because you live perfect. So what we are going to do now is we copy a few things from our website. So the script is below. What it does is it just runs Docker, or Docker play, which is a non development, just a small play version. And we use the let's use six for 15. Oh, I don't know if the new one is already published takes a while that came out today, but let's just use this one. So we have sharper six 415, zero, we name it sharp and we use the port HTTP to port 80. Then we just yeah asleep 20 seconds and output what is going on, then we have a local house and the running inside that Buddy action. Then we Notification Centre. Copy our plugin content, which is just the current directory into the plugin folder and shopper. We do some Yeah, permission stuff. One liner, then we instal and activate it. And then we allow s folder. Cypress folder is already installed. And then we use the official Cypress included 10 Eight zero latest version to run against our local host. And the content is the current directory is mapped to the directory E to E that is required. And then it's working. So safe now. It's run Cypress.

So, actually, I think that should fail because of the new shopper version. I didn't push my changes. So let's, we'll see. We'll see. But before we'll see, let me just push it and we see how Buddy is automatically being triggered. So we have our new tests. Yeah. Excess. I'm not gonna argue about that commit message with whatever so. And Buddy is

technically Exactly,

exactly. So we have in the QL CI/CD For our current commit, fixed fix test. And as you can see, the rest is already cached. So it's just a few seconds.

And this now takes a bit while it is running, just Docker of the whole shopper being downloaded. It's not five megabytes. But what I totally recommend when when doing it, if I just go to the other pipeline, my backup pipeline here is there is there's plenty of things you can use the configuring these actions in Buddy, there is a attached cache drive to virtual machine running this action that will cache your darker layers. And if you also use the shared cache, and you can even use some tags for it, you can share those Docker images across multiple actions. Cool thing didn't work in my my Sass because of the size. But you can also use the on premise version or I think have your size being increased. But this is just Docker is isn't that small. But this is a cool thing to to cache things and speed up the running process for further costs. So back to our action. So

we are near we are near the end. I see. Yes.

So we should now after 20 seconds gap the output of darkness we've provided a boot up script with a nice title a hidden hex based encrypted text that you could decrypt and let us know. And some some stuff, URLs and things you you would want to know. Down there. It already installed. Oops, already installed our plugin and extension, cleared the cache. And now Cypress is already being started. So another Docker image, not that huge as the darker one. So it should only take I know under a minute probably And then the Cypress tests are being started. Yes, I did not add test grid integration for now, because we have our backup pipeline, which does a bit more, because I still own you that the other mode of my test road integration where it creates new test runs on the fly. This is the reason why we start the pipeline in a minute. But now let's just try to figure out, did it work at all so far with the integration? So let's just

do the waiting part is sometimes quite long. I wanted to mention that every time I have a webinar with you add, I really admire the fact that you every time remember to name each step and everything. It's a small thing that I always forget. Yes, point. And at some point, I remember that, yeah, I should start correcting those steps called I don't know, because, by default, it's execute, for example, NPM, instal. And I have four steps called execute NPM, instal. And I don't have a clue what they are doing. It's so yeah. So so really, I, I know that this is a small thing, but I totally admire that you always, always remembered.

Thank you. Yeah, it's the small things in life, especially when it comes to developer experience. Make open your eye with that thing. Because you use switch across projects, you switch across different programming languages, the easier especially with testing developers have it, the more they use it.

So I asked the

past for yay, who would have thought that that might be passing? Me. Anyway, so awesome. We did now completely insight Buddy, run a four tests of our shopper plugin with a real shopper six 415? Zero. So let me now show you or run the other pipeline. I hope it's still cached. If not, then at least I have some time explaining you what we are now doing. So because this

is this part about automatic, automatic creating the test runs.

Yeah. And it's always if you if you wait for it, it takes ages, but it's meant to be run in the back. So whatever. So I have a bit of more in here prepared. So normally, in a CI CD pipeline, you have more than just running Cypress tests installing a plugin, we have we instal the dev dependencies, we run PHP, Stan, you would also do unit tests, you know, these tools, what I would recommend is there's a trade off. If you have PHP and PHP unit, chest es lint and more. Below beneath next to each other, you have a core great visual indication on what is going on. But it's a lot to maintain. So what about a make command make review that just executes everything inside. And the good thing is your developers could just use it locally and have the exact same QA pipeline except Cypress that is being also run on with the static analyzation static testing in the pipeline. Nice thing, and you could extend it without touching any pipelines. So next thing is we create a cypress dot n file. How does it look like? That's the last thing I'm gonna show you besides the result that we just see. This is our action. So we are creating a dot and file on the fly. I would never just to let you know Upload Files embody to us it always created on the fly, because we one day had some caches, and those files were cached. And we were wondering why the new configuration wasn't really used. So created on the fly inside echo piping output to a file, and then that is the dot n. We have those things I wasn't able to show you locally but here we can use easy variables that you can configure for workspace trust in your pipeline trust in your project. So now I can show you because I don't show you. But what I will show you is those things. This is the second way how we can use my integration decades. So we have a project ID industrial we even provide a milestone. That is, in our case, just the Buddy CI/CD runs for whatever reason. And then we provide a run name and that body run name is Buddy CI/CD, then the variable of Buddy for the revision subject, and then something that I built a datatype placeholder. And then the end, we want to close the run. So if that is now solid and passed, which is a good sign, we have our Cypress tests, run in test run creation mode, everything passed, and it's closed and results are sent. So if we now go to the test runs in test rail, we have a new closed, Buddy CI/CD, improve Cypress tests with the current date, and it contains our results. So just one test in that case, and the header compared to the existing test run because it might be different now it's always the same is now in the description of the test run. So now that we have that system up and running, QA could just tell me Hey, Christian, see, 11 is pretty annoying code, you automate it. And all I do is I use let's say it's this one, code it at this one, and I'm done. And it's all completely automated. So I would say, that's it for now. Thank you for watching.

It was truly amazing. It was truly amazing. Really mind blown mind blown. I mean, this is, this is a true example. Because that's just the beginning this flow, when we start first, manual testing, then we start automating things, then we start out automating the automated things because we see that we that we lack of the lack of the reporting, because when we started to, because a bit differently, we had such a simple plug in right? It was, I mean, it could be two simple as what it was four fields, yeah, four or five fields. And we were able to create so many tests out of it. So it's really easy to imagine, how many tests are those

ecommerce projects? Yeah,

exactly. I mean, even such a notification bar, it's kind of useful, but it would probably the real one should have also the URL. So onto closing out the opening, so the number of our actions would grow. So our test cases would also grow in a very, very quick amount of time. And without reporting without having those cases how to do it manually. I can imagine that at some point, either, we will just pretend that we are testing everything. Or we will go nuts, because of the manual testing. Because let's be honest, manual testing is boring. In most cases, only the edge cases and only the first time when we find, oh, this is an interesting bug. The rest of it is like it's horrible. It's just a horrible experience. So the case that you show how to use tests, right how to write those scenarios, because writing those scenarios is something quite new to me. But it's it's logical. It's really logical, because like we mentioned before, we can show such a scenario to almost any person, and such person should be able to follow it and serve our awesome. That's something cool because we don't have to test it anymore.

May I just add one thing if it's new, just to to let everyone know. There are different principles of testing. So there's one thing that automated tests are super those scripts are things but they don't find new bugs. So always keep in mind this haps for side effects, regression tests, but always do manual testing. In addition to this, very important Yes,

exactly, because every time we would follow such a scenario, Cypress will just Follow it and don't mind a bug that happened just outside of our testing zone. And the real user will be able to see, okay. Every time when I, for example, switch, the active does activate button, the page Reloaded, or something like that. So yeah, that's why manual testing is also important. From what I see, sadly, we don't have any additional questions about still, thank you. Thank you so, so much for this. Like I said, I learned a lot and I really hope that everyone learned a lot too. So just do some some additional things to mention. If you like our webinars, don't forget to join our Buddy CI/CD group on meetup you will be informed about all the upcoming webinars. And also don't forget to subscribe to our YouTube channel and also Twitter, Facebook and LinkedIn once depends on where you're active. And of course, do not forget to follow Christian on Twitter. You can see his his Twitter handle handle near him. So thank you all we will see each other in two for in four weeks, we will have something about about e commerce. And a lot more detail details will come soon. So thank you, everyone. Thank you, Christian once again, and I can't wait to have yet another webinar with you because it will be for sure it will be amazing. So thank you, everyone and have a great day.

Thank you. Take care