 All right, oh, it's 11.45, so I may as well just kick it off because the sooner I'm done the sooner I can get food So hi there, I'm Mel. I'm one of the lead developers a hide-and-seek digital I've been a full-stack developer for too long So I'm always on the hunt for ways that help me spend more time doing the things that I love like solving complex problems or just getting that extra caffeine boost in my day in This talk I'm gonna take you through leveraging Cypress in Drupal to optimize your testing processes Which will save you valuable time for both yourself and the entire team When deployment day rolls around and you find yourself as a sole developer Responsible for a considerable number of sites Testing can often become a challenging task It actually might look something like this All right, I've gone to dub dub dub my site and it loads. Thank God. All right, but I should probably test my search Cool done a search. It's bringing back results. Oh, it's testing so easy Finally, you should probably check that the document types still work and I can download things Awesome. Oh, that's still loads. Well, thank goodness for that. My code was perfect I'm done So you've deployed the websites and it's working you've tested it after all Everything's great. You believe this to be true because it's been a few hours No one said a word to you so you get back to doing the things that you do best like develop things Now it's been a few days since that deployment everything's roses and went out of the blue You get a critical support ticket labeled broken page You open that ticket to see the attached screenshot How'd you miss this? You checked that page. It loaded fine Of course in the case where there's a document body It's got conflicting styles and something's breaking the download links Something like this has probably happened to everyone in the room and look most times. It's a time crunch issue You don't have time to test every variation of a page template Multiple searches and then even everything that a content author has to do Usually we're also times in these tests by like five or more Because many of us are working with multiple websites daily not just Drupal This is where Cypress can step in to give you a hand Cypress for those who don't know is an end-to-end testing framework for web applications It allows us to write and execute tests for our web apps quickly and efficiently Cypress provides a user-friendly interface for writing tests and offers various features such as Automatic waiting real-time reloading and built-in debugging tools to help developers create robust and reliable tests Additionally Cypress provides a powerful and intuitive command-line interface making integrating with continuous integration and delivery workflows easy Basically Cypress runs in both a headless mode and a head of mode Cypress is deceptively easy to set up on an existing project. It's as simple as running MPM install Cypress save dev Once installed we have a folder structure for Cypress that contains your end-to-end tests. I Put mine in different folders, but you don't have to you can put them all in the root We've got fixtures. These are data sets that you are not going to change, but you're going to reuse a lot and We've got support which contains our custom commands and also additional plug-in setup We also have a screenshots and videos folder where test outputs are generated on the right We have a basic Cypress config file But we set up the envs with either a dot env or a Cypress dot env file because you don't want to accidentally push up public things on Your repositories told you max Cypress can test against many different browsers and versions by default it detects what's available in your machine But we can either download anything missing or use docker to also spin up the missing browsers Cypress has an experimental support for webkit, which is what Safari's browser engine is using so it's a little bit more config to set it up When we're running in a headless mode We need to set the browsers using the browser flag by defining this or by defining this in our Cypress config setup Speaking of setup, let's get into how we can use this to create tests The bread and butter of everyone's first Cypress test is automating the exact situation. We just went through Cypress can visit a page and do a set list of actions and fail for us when it is unable to reach any of the steps This kind of test is good to ensure that a user is able to get around the site without an issue, but This test does not care if your site is broken or styles are wrong We're only really looking at the data stored in the HTML So that brings us to our next type of test Say you've gone to style a button on a document page You've tripped over and you've accidentally applied that style to all the links on the page While this is an extreme example, we find that large sites have complex styles and is incredibly easy Even in the days of linting and prettier to accidentally forget that one parent class To allow for Cypress to capture a baseline of your page and then compare it to a new screenshot I use an open source package called Cypress image diff.js, which is a bit of a mouthful But basically it's a set of helper commands that will do this all for me So let's see it in action It's evident that the test has failed because in the new screenshot does not meet the thresholds that was set That button is blue. We're expecting green When the change is not as obvious as us doing a major color change This package also provides assistance by generating and displaying diff image files in the diff file We see the problem elements in red To help where things went wrong, it's also muted the rest of the site so we can quickly locate the changes as well And the code for this test is only seven lines Now that test before gave me an idea One of the key teams that we work with are Designers, and I'm sure I'm not the only one who's had a ticket go back and forth over the padding of components So how can we use Cypress to help us ensure that the component we've built follows the same fail-on threshold rule That package before doesn't really help us, but it's using something called pixel match to do it smart So let's hook into this Our designers use Figma as their tool of choice. There isn't any reason that this couldn't be adjusted to like Adobe XD As long as you can get the component with API you can generate a test like this Here I'm finding the button component in our design library and then storing a screenshot of it to test against Next we need to grab the component off the website and grab a screen to grab at that too I'm going directly to the home page You probably don't want to use your home page as the place where you test the buttons, but for ease of use We're going to deal with that Finally, we need to compare these two screenshots using pixel match In my case, I've written a little nice little reusable function here. I can call it multiple times for different outcomes It's also for different components. You want to use it against many tests. This is kind of where that would go The first time I'm using it. I'm simply making the return fail when the difference comes out greater than 10% and Finally after this happens I need to be able to get that diff image file that'll show me as before in red what parts are different So our first round is a success. Yay But then we've decided to experiment a little bit and added more of a border radius and change the font from upper to lower Now it fails and it prints out this diff image for us to see the problem areas again I've gone through tests that solely focus on the front end of the website But there are two parts of Drupal and one very important user group your content authors And we can use Cypress to ensure that they can still do all the things that they need to do First off, we want to create our own custom Cypress commands so we can use this to run drush commands I've made this one that'll create ourselves some dummy users Just want to note the drush path here Because I want to be able to run my test locally and on my hosting provider of choice I need to be able to switch paths from Lando drush to say platform drush It really depends where you need to call it from With this custom command, I call it in my tests creating the user and ensuring they can still log into the site without an issue but Continent author is going to probably want to publish content So we can write a test that will follow a content author's journey to create this in my case I'm doing this as an article Then we need to check that the page was created successfully And then we need to remove it when we're done because you probably don't want to have a hundred test articles on your site So we should all be getting a good idea of how this all works at this point Cypress everything is broken into set Our first round we're creating our dummy user against again with that command from before Logging them into the site and Then we want to start creating an article and I've created some dummy data that I've stored in a fixture because I want to use that again and again Finally once publishing we need to check that the page contains the title and if so, we're going to delete it Currently, I've only gone through what I've gone through only really helps an individual There are no rules in place to have your team also use these tests and as Dom once said many times in the Fast and Furious movies We don't turn our backs on family So how do we include this as part of our build and I'm going to go more into pass here But for sass users where there's a will there is a way I'm going to use github actions as an example for this, but or repo hosts have a version of this Having Cypress run for your team can be as simple as adding a github action It simply changes the base URL and drush path to your development server In here, I'm simply saying on each push to stage. I want to run my Cypress test But in this case I've said I only want to run the button one Removing that spec means that all tests were run Finally, I want to save the Cypress output when we're all said and done as this will help us find the errors as we run on a headless mode in a visual way Now Cypress also has this thing called Cypress dashboard and essentially you can hook it up and it will store those Videos and images for you It costs money once you get past the free tier and I'm very frugal. So I like to find free ways to do things now As with many things in life, this is just one way to run Cypress for teams There's about a million ways that we could handle doing this Another way would be to include your Cypress test as part of the build pipeline run and that way if they were to fail on stage You build wouldn't go out at all That might be really annoying if the build fails because you've moved a pixel five five to the left But it saves you if we've just destroyed an entire page Well now that we've got our teams using the test That's great. How do we then use this to justify the dreaded change release request? Cypress also has a handy plug-in called the Cypress Moco awesome reporter And it gives us the ability to take these tests and export them out as HTML reports Now you're probably thinking I can't upload a whole HTML microsite to my change request release Well, we can use puppeteer to then look at that HTML and generate it out as a PDF file Which you can then connect to your request Now you have something to attach as additional proof of the stability of your build because sometimes word of mouth is All the tests that we've gone through today can be found on my github I hope this gives you the kickstart that you need to get some automated testing in your Drupal projects Just a couple of things that we need to note Unfortunately, your tests are only as smart as you write them. I know weird but The benefits of that is because the web things that we work on change every single day your testing requirements change every single day You're only having to adjust those tests to meet the needs and as a human It's really easy to forget steps, but a test an automated test isn't going to forget something It's going to do exactly what it's told And a super unfun fact is Cypress 12 is not data that chat dbt has a lot of right now So it tends to spit out the wrong answers if you use it But apparently yesterday. It's just recently allowed itself to open itself to the web in Australia So it can actually search things now Cool any questions The things that I've noticed with it So basically was the question was have I used Cypress with web forms and it's yes I have the only con that I have with it is there's a lot of a weights because you kind of have to wait if you're doing like Ajax or something you have to wait for things to happen and depends on how fast you're like What you're using your internet speed with because you put a wait for like one second that might help 90% of the times but then you have that one time where it's going to go over just a little bit and just go off that threshold It'll come back and fail It's like front end and like the back end stuff because you can use it to do It's not like just where you write like unit tests or anything like that It's solely focused on the user journey more than fun. Yeah