 Thank you, Trisha Okay, I don't have my many slides So I'll just quickly go through and then we can go for questions. Stop me anywhere if you have any questions Sorry Okay, so how many show of hands how many of us know Cypress already? Are you using it in your work? How about you? Okay, anyone using javascript based selenium night watch js kind of Okay, okay That's good. So So let's see What we are gonna see here I would like to talk about the challenges in modern web automation. So we started with Open source wise we started with selenium assi So but now we have a lot going on in the web automation right even in the web there are a lot of frameworks especially in the JavaScript side and Since most of us will be familiar when open source It's most of us will be familiar with the driver. So I would like to compare web driver with Cypress How does it compare and then some key features in Cypress that really stands out when compared with other tools Yeah, and other basic concepts with Cypress and if possible a demo. Hope it doesn't break Okay, so in looking back the Web will be mostly a server-based rendering right Lot happened on the server and very little happened in the client and the server sends a HTML page and the browser just displays it That was long back, but now we have come to a Advanced state wherein we can do everything from the client side itself server is just Rendering the initial page and the client by using the javascript Makes a XHR request and a lot of Ajax request happening But selenium assi or web driver was built long back like in fact 10 years 12 years back, right? So It wasn't really catching up with the latest happening in the web automation I'll explain why in the next slide and There are a lot of improvements on architecture a lot of Happening there, but the web driver wasn't really catching up Okay, so key difference is stop me whenever you have any questions. I'll try to address as much so the key difference is Web driver is synchronous synchronous in the sense There are four major layers in web driver one the client bindings which we write automation code and then the server which Gets the request from the Bindings and then we have the browser driver and then the actual browser. So there are four major layers to it and as you see due to the Rest API call between the client bindings and the server every call is synchronous call right Hope I'm making sense here whereas But let us look back at the web So initially a client request for a web page and server gives an initial page and then a lot happening in the client side right, so We all give a you all but then the browser request multiple the JavaScript request multiple pages in between and then Without any page refresh it displays in the browser Right, but from web driver point of view We just give the you all and we we don't have a real understanding of what's happening behind the scenes right Whereas in Cyprus the Cyprus process runs in the same loop as the Web application, so we have we have the hold on the We have events happening in the website so we can React to the events that are happening in the website and basically we can validate the events And the other key difference is the retry ability in in web driver we have to As as sham mentioned we have to look for Web elements and then we have to iterate through it look for it wait for it. There are different weights Available and it's up to the implementer to really In use it right and and iterate it as a as an when the page loads whereas in Cyprus the retry ability is inbuilt so for a To give an example when we Make a request in Cyprus Cyprus will ask for a page and it has a hold on the Website and it wait until the event is happening and then it fires and and then it validates again The other difference is multiple selectors versus CSS In web driver we have multiple selectors ID We have CSS we have XPath but unfortunately Cyprus only works on JS because that's how it's built and The other difference is HTTB stateless and stateful clients. I discussed just now In web driver it is stateless meaning The we all have URL and we send it. We don't know what's happening in the browser site It's just stateless whereas in Cyprus It's stateful because Cyprus runs in the same loop as the app and it knows what's happening in the browser site And it can react based on the events that get fired in the browser Right. This is a key difference. We have with Cyprus and the other difference is end-to-end Web driver we can do only end-to-end meaning we cannot really stub responses We can only make a request and then it hits the real server and then gets the response back And then we can validate the DOM whereas in Cyprus we have the opportunity to do integration level test as well Cyprus has access to the JavaScript code from the app note code as well as it can run unit as it can import JavaScript file from the app code and it can run test against it. So basically we can Write a hybrid level test in Cyprus. Whereas in web driver we can write only end-to-end test this difference stands out when we have Network request which takes time whereas in web driver we can make a request and how to wait for it but in Cyprus we can mock the response and then validate the client site and And another point I missed out so web driver The browser driver is implemented across major browsers whereas Cyprus works only in chromium chromium based electron we have Canary we have chrome so these three browsers are supported Firefox support is is in progress, but it's still not implemented it Sorry Headless it works in electron, but still not there in Okay, future wise we have something called time travel. So time travel is nothing, but we have the option opportunity to look at the DOM state for each and every request before and after the request is made I'll show you in the In the test runner so we can have a really look at the DOM before and after the request is made to the made from the browser and Debugability we can stop when the test is in progress and look at what's happening in the dome Right that that really helps us whereas in web driver. We don't have access to the chrome dev tools We don't have access to the other underlying network player resources whereas in Cyprus we have the ability to do it and Another thing is real-time reloads We can Retry and real-time load the request from Cyprus automatic waiting in in web driver we have to make explicitly the weight and then iterate on it or Put in a loop and wait on it Whereas in Cyprus it's inbuilt. We don't have to really write a code to iterate through a way So every time when a request is made we have a timeout specified in the configuration and until the timeout is made Cyprus automatically retries the command spice tubs and clocks. It's It's it's it's related to the network request. We can stop responses and then look at the How the client displays it? network traffic control We can even in the end-to-end test we have the opportunity to look at the response and validate it Whereas in web driver. We don't have access to the network responses This is one really good difference consistent results This is related to the flakiness which we discussed I hope there were like multiple questions on the timeout. The reason is I Just said we had four layers in in web driver, right? Irrespective of the implementation here we have at least four layers So the moment the request is sent from the client binding We don't really know what is the state of the Application in the browser Right, we have a notification when the page load is complete But between the pages initially loaded and the page load is complete We don't really know what it is happening in the DOM and we really shoot in the dark assuming It's there and if it's hit it passes. Otherwise, it's a flaky test Whereas in Cyprus as I said earlier We have access to the DOM at each and every Request made and we have a control on the events fired in the app and then we can validate on the responses, yep and Sham also mentioned about the screenshot and the videos for apm, but Cyprus gives you Yeah inbuilt we don't need to write any code for it. Just it just there okay, so Cyprus is built as in NPM module, so basically it's a binary and a wrapper on on a node module We can also install using yarn in windows if you install npm then it's it's pretty simple It's the same as npm install Cyprus Yep, I'd like to show you the installation from command line. I Have I terminal Is it visible? Okay So I'm making a directory So I have npm installed already Normally that Cyprus code is Developed along with the app code. So since I don't have access to my app code here. It's it's confidential. So I'm just Trying to create Empty module so this creates basically a package.js on as you can see so if we write from the application source code Then we'll be having a lot of libraries here and the source code here so So next command would be to install Cyprus So this install Cyprus as a node module within the local the repository in which it's installed Save Dev will add as a dependency In the package.json There are some warnings, but yeah, it has installed already So as you can see we have node modules now So now we have more node modules and we have the package log.json and package.json I'm opening this in Visual Studio code Cyprus is added as a Dev dependency here Okay, so package.json is a dependency Manager for to maintain the dependencies Okay, so before an app is built Whatever versions that gets installed as a dependency for the project a lock is made for that so that it doesn't change Yeah, so if we if you want to change the version of any particular library, then you have to delete the lock and then Run but let yeah, then install again So we have Cyprus added as a dependency here under the node module so we run Cyprus now so Cyprus is under the node module bin and then I'm just opening the Cyprus test runner So this opens up an electron app so Cyprus has a pretty good documentation already so as you can see a Lot of examples specifications that are built by the Cyprus team So we have if we look at the project directory So Cyprus has created a directory called Cyprus So it has created a directory called Cyprus and it has created a file called Cyprus.json So all configurations that we make for Cyprus goes under Cyprus.json for example If we want to give a URL that we want to test against then we can put it as a base URL there We can configure the timeouts. Yeah, extra So now I have the test runner We can just Target the run against the browser Currently, it's Chrome 73 as you can see at the right top Okay, let me run anything so it opens up Cyprus own browser Chrome browser And it runs the test against the website So this is a sample app built by the Cyprus team example.cyprus.io and it runs different Test against it. So we I'll go through each and everything in one by one Okay, so when we install Cyprus and opened it what it created was Cyprus directory right so under this Cyprus directory we have fixtures and we have integration and we have plugins and then we have support so fixtures is something which Any data that we want to use in the test or specifications we can put it in here And all the test goes under the integration we can subfolder it and we can run only the specifics of folder for for filtering and plugins any any Capability that we want to add to Cyprus that goes in here For example, we can Cyprus by default supports only CSS Whereas if we install another plugin, then we can Cyprus supports XPAD also so those kind of plugins going here and support any any Command extension for examples of Cyprus supports default commands and These commands could be overridden or can be extended or new commands can be added also So that could be added in the commands.js Okay, as I talked about there are different configurations base URL and environment environment We can target against different environment Timeout there are different timeouts here default command timeout is what The timeout that specifies the amount of milliseconds that Cyprus wants to wait for each and every command and Page load timeout is what when Cyprus request for a page and it waits this much time to for timeout As I said, we can also make custom request and we can Specify the timeout in the request timeout. We can also specify the timeout for the response also and For folders we can customize the videos folder fixtures folder plugins while we can keep it in a different folder as As we want and then configure it in the configuration Cyprus.json Okay, so from concepts wise Cyprus borrowed different concepts from different frameworks. So the test structure concept was borrowed from mocha. So anybody work with mocha Then it will be as Familiar to you so we have We have Something called Specifications which contains a group of tests we can target against So inside a specification we have a described block and then inside the described block we have context and Inside the context we have multiple test cases Right, so it specifies the test cases block. So we can either use specify or it so it depends on the user's preference so the The format follows the JavaScript Specification so everything is written within the parenthesis. So we should really get used to it Actually, it's a bit learning curve when we come new to JavaScript But once we have it then it's kind of easy and then we have something called hooks hooks is something that We can prepare the test data or we can do some Specific steps for each and every test before we run the test we can use the hooks for For running the steps for preparing the application to be in a specific state We have before block we have after so which runs before every test specification is run and after is for any any Steps that we need to run after all the tests in the block is run before each runs every Before each runs every before the test block and after each runs every test assume case wherein we have more than 20 or 30 tests in a spring single specification and Cypress has an option to Run the test automatically as and when you develop the code and save it So there's a watcher that runs the test automatically So if we have a number of tests then each and every time we save the specification file All the tests will be run which is we do not want that scenario, right? If we want to run only a specific test case then we can specify it that only then only those Tests will only that test will be run All the other tests in the specification will be ignored Skip is exactly the opposite if you want to skip a specific test in the test specification Then we can mention it in the in the it block and then only that particular test will be ignored okay, so We have something called commands as an as we have with the web driver as well So we have different querying commands query that queries the DOM so we have visit method to Go to a particular website or or a particular path in the app Or we we have get method to look for a specific element within the DOM And then we can do an actions on it and there are action ability commands as well So we can click on an element double-click on an element type some text in a input field We can clear the input field. We can check and check boxes unchecked. So there are different inbuilt Action ability commands as well querying commands as well within Cypress As you can see in the code block We have a visit command so visit command specifies the relative path the absolute path is picked from the base URL So we can specify the domain name in the base URL and we can specify only the relative path in the visit Yep, so we also have something called assertions So we query the DOM for a specific element and we can do some assertions on it right, so there are different Assertions and commands retry the assertions automatically for example, let's say we look for an element in a DOM and Due to some XHR request the element is not in a specific state. So within the time out Cypress automatically retries the Command and the relevant assertion. So we don't need to really write the Looping ourselves so Cypress automatically takes take us of it and There are different assertions from Chai framework. We have implicit Which is should Should contains different selectors in it. So as you can see in the code code block here We can run a contain Selector we can check whether a particular tag contains this particular text. Yeah, so there are multiple Selector cases which will be really tedious to go through now. Yeah, and as I said earlier We can also stub responses if the network request takes a lot of time then we can Stub the responses put it in a Put it in a fixture and then stub it to the request so that we can validate the url And also we can do assets on request and responses There was a time when I was using Python web driver and I had to really look at the network response request and response But web driver by default in wasn't able to give it so I had to look for work around by the time I Use the request module to to make a request and then validate it basically so But but when when I switch to Cypress it was pretty easy Yeah, so we can we have the hold on the request and the response which we can validate Fixtures as I said to manage any data in the test we can pass the fixtures to the test and then invoke it at runtime Web driver we have a famous framework page objects, right? So Cypress out of the box. It doesn't have it But there's a workaround we can create page objects in Cypress as well But the Cypress team supports using custom commands. So instead of page object as I said in the support Directory we we can have custom commands for example when we frequently use a certain command We can make it as a custom command and then work in all the specific test specifications and The other important concept is alias If you look at these two code blocks before each is a hook and it is a Is a test case? now we need to pass the Text value that we found in before each to the it block Right. So normally we we can create a variable on top of the specification and then pass it around from JavaScript but If we use an alias alias is nothing but dot as as text. So this is an alias So using which we can refer the value from other test blocks as well So we can pass the values around Okay, so another important concept is timeout as with the every web testing So we have the option to set the timeout at the global level which we do it in the configuration as well as we can specify the timeout in the respective command itself The reason being by default the timeout is four seconds, but we can chain commands and assertion in a Cy driver, so it's a side driver. We can chain commands and assertions in it so all these assertions and The commands they have the same timeout specified in the global So what if these takes more time? So then we have an option to specify the timeout exclusive for this particular command So normally it's four seconds, but this timeout is ten seconds because we think that okay this Assertion will take more time. We have the option to do it. Yeah Okay, so any questions until now Okay, so I'll go back to the code Go back to the code which we wrote earlier. So we have the cypress direct, sorry So we have the cypress directory and we have fixtures in it and integration is where the test specifications will go into So I'm going to write a simple test So I've created a test specification and the integration Javascript stack sugar Just gives me the references by default So as I said in a test specification we start with the describe block Okay, so we give a description for the describe and then We have the function Yeah, so we write everything within this describe block So we have we can write a block So instead of function, we can also write using arrow function. So it's a lambda function So size or driver so we can visit any particular side So we have the test runner now and you can as you can see the test runner is able to find the Specification which I just wrote so when I run it Visits the web page and it's done right but as you see We just gave the you all google.com but cypress is able to identify whatever a jacks request the site is able to make So if you want to really test the entirety of the application sometimes if you want to Test the XHR request as well, which we can identify from the command log So this is a test runner and this is the command log so command log watches over the request and response and it saves the Dom state before and after a request is made as you can see in the but in The browser here at the bottom So it has captured the dom snapshot each and every time when a request is made as you can see here and Also, we have the option to inspect the Dev tools inspect the application using the Dev tools. So that's one another advantage with Cypress Yep so as you can see the test runner it's It's pretty handy so it tells how many tests were passed and it tells how many tests were failed and this is the total time it took and Each and every test it It watches what all the different records that made and what all the different command that get executed And all the different decisions that were made whether it is a pass or not And this we call it as a command log. We have the option to rerun the same test again and this is a URL preview it gives you which particular you are the Dom the site request was made and there's something else called viewport We have the option to run the website at different Devices so we can specify. What is the length and breadth we can run it against a different Length and breadth of it and this is the app review, which which which is shown for each and every dom snapshot Yep Yeah Yeah, yeah, so as I said Cypress gives the opportunity to debug when the test is around so we can Give a command like debugger between in the test specification. We can specify the word debugger So the test stops at that point and we have the opportunity to look at the dom state at that point Yeah, and also we after the test is run We there's another option called dot debug. So which is also helpful in in verifying a particular state of the of the request Okay, so I'll just so all the time we have seen the Cypress in the dev mode, right? So as you can see if I make any change in the code the The Cypress watcher reruns the test automatically Let's say It's okay. I'm going to open another Repo give me a second. So I'm invoking Cypress at a different repo The Cypress opens up the runner. Okay. I have another test here So which I run which is basically going to Google and then look for a specific search for a Word and then open its first website Right. So as you see here visit is not this particular test is not executed because I might have skipped it Yeah, so I have just skipped it So I'm removing the skip and then saving it Cypress will be able to automatically detect that some change is made and it will rerun the test automatically Now it has run visit Yeah, and Cypress uses by default same origin meaning we can test only a single Domain for example SG dot carousel dot com right, but what if we want to navigate to different domains, especially on the XHR request We want to go to different sites. We have the option To disable it so that we can specify in Cypress.json So as you see here, I have disabled the Chrome web security. So it When this option is specified Cypress can Navigate to different domains Especially in end-to-enters will be needing to move to different domains, right? Yep, so okay all this while we have seen Cypress in dev mode, right? So what if we want to run in continuous integration, right? So we have another command called Cypress run Okay, I guess it's not visible. Let me bring it up. Okay. So we have the option to run Specific cases so assume we have multiple specifications, which we want to run But we are interested to run only a specific case then we have the option to specify in the command line when does this run by default Cypress uses electron browser not chrome We have the option to give run in chrome by specifying the browser So this runs in headless it doesn't open any browser So it's running invoking the test It's running an electron browser Okay, so it ran two Test cases and it says all past. So if all the cases pass, there'll be no screenshot obviously But as I said by default it gives a video, right? So this is the video it could create it Playing the video So we didn't do anything right, but this is by default Yep, there's a slight issue here as you notice the last step is not complete, but the video is complete This is a known issue and on on Cypress Okay, so you've seen Okay, I would like to fail a test and then show you the screen shot as well so I purposely made the Test fail It as you see it took some time, right? So it retries the looking for the element So by the time the timer was reached it just came out As you can see for failure test we have the screenshot. So we can look at it and then See why it's failing So the screenshots will be available under the Cypress folder under screenshots and this is the screenshot That's just created. I purposely look for element that was not available here and then Cypress failed in here Yep, it doesn't Okay, so for logging the error we have the If we open it in the development mode, so we can have exactly the DOM state white fail Yeah In fact, we can From the failure at that point we can print out the error in the console and The error, okay, I can show you the video Okay, it will fail at this point But will the video captures what I'm thinking So here you can see the log Cypress error timed out retrying expected the element Locator and then to contain a particular value, but it wasn't there Yep So we have seen this There's plenty Available on Cypress, which I haven't covered Dashboard is something which is a paid service for a private repo in github and For public repo, it's free. So we can use it In dashboard, we can see the test insights how it's run What are the cases fail? It's something like a paid version and Paralysation is not that great in Cypress. I would have to agree with that The reason is the way it's run in JavaScript. It doesn't Yeah, so it one it doesn't support cross browser and the other it runs within the browser and it doesn't support Paralysation for parallelization right now the state is we have to run it on multiple machines Yes, as I said debugging, I haven't covered much but there's an option to a debug during the test Yeah, it helps a lot and There are references Cypress has done a wonderful documentation They have in fact Explained what Cypress can do and also they have explained why it's done that way So it's really great in terms of documentation and brand man is the one who Develops who's founded Cypress so you can find his Intro on Cypress at this link. Yeah Cypress repo. It's in github. It's open source. You can very well Look at it road map As I said five fox support is in progress not sure when exactly it will be done But there are other priority features as well in in in pipeline The sample apps I have shown you is one of the app there are plenty other apps which Cypress use for testing So you can you can see it in the sample apps link Yep any questions Okay Right now we don't have I mean Cypress doesn't have Selenium grid kind of architecture But dashboard is something which we can look at it. It helps parallelization But it's a paid service for private repose