Plone Conference 2021 - Testing Volto Addons
CC Attribution 3.0 Germany:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Gulia, Nilesh
Showcasing Volto's testing infrastructure and framework along with tips on how to achieve a strong QA among volto projects and addons by adhering to development workflow.
 Hi, welcome back to Plum Conference 2021, Track 1. We are here with Nailesh and he is going to be talking to us about testing Volto add-ons and the testing infrastructure. Hello there, thanks, Andy, for the introduction. I hope you can hear me. So a little bit about me, I started contributing to Plum Volto since 2018 when I started as a Google someone of course student and now it's been almost two and a half years and I started contributing to Volto Core as an individual contributor and now currently I work as a front-end developer at other web and since two years Volto has been like evolved a lot when it comes to the extensibility story, the theming, the development workflow and like add-ons and the blocks especially so everything. So this talk will be more about the add-ons like the testing and add-ons like how was the testing infrastructure evolved in Volto and how did we extended that to further add-ons. So let's talk about it. So like Volto we have a generic text setup here like so we do a three-bunch testing in Volto like the unit tests and the integration test and the end-to-end test. So first unit test is just basic unit tests which are basically return we are just the just is basically a test runner which runs and they also provide some out-of-the-box accession tools for us. So another thing another tool we use for unit testing is React testing library so it provides us out-of-the-box tools for these snapshots and for the more or less the accession way of testing writing the unit test. So basically unit tests are the important part of our code. It basically validates what a developer is writing. So like we aim to have like above 90% coverage but yeah I mean the unit tests basically are the very important thing in our in Volto in every front-end code and then next is we have the integration testing like in integration we have CI right now we I think move to meta workflows and actions and before we used to have this Jenkins and like Travis and also we run these tests on like everything in the just Cypress and every link in the CI and the other thing which I really love is the end-to-end testing we heavily rely on Cypress for it so Cypress is a tool which does the end-to-end test for our add-ons or for our projects or whatever it is. So like it validates what a user has written and it just text end-to-end workflow and applications from start to end and whether the code return has some flaws or whether the feature is working or not so it's basically a Cypress which does the magic so it's basically fully controlled by automated software and runs using a headless browser so I will talk about it more we will go into a little bit depth about the Cypress mainly and how they testing is how the tools what are the tools we use in Volto. So like what's the like motivation behind like why do we need to test I mean we the Volto code because it helps to reflect our add-on to a better design so we tested it rigorously and we write unit test write the acceptance test for it and we can you know we know that what part of the add-on is breaking and what part does work well so that's why it's helped to we can adhere to good guidelines of the research the testing guidelines so that we can know the breaking parts in Volto the add-ons the second I think is yeah I mean we as I said earlier we have already matured set up in Volto and we would like to you reuse that setup in from Volto we extend that setup to add-ons so we have several tools for that and it's basically these the extension they are basically the custom customizable so we can customize it we can override these and so we are just making the use of the older which the setup we have to we have already involved this also saves the developers time and also yeah the test they run in CI and is the same as the local so this local and the CI they are they run one the same so it's not like a developer point of view not kind it doesn't create any separation developers perspective and also like as I said we have the end-to-end test which which are really I would say the checks the authenticity or the the vulnerability within our add-ons so if so it checks the from start to end the every single component of an add-ons and it also shows in shows that the add-ons which have the add-ons should have the stronger connectivity because we have many projects that we have different add-on we have multiple add-ons I think 20 30 add-ons and we need we don't know which add-ons is it dependent on another add-on that's why that's how the end-to-end test comes in handy so it automatically identifies which add-ons has another add-on dependent and we can identify them and yeah it's adaptable to needs so basically the testing they are basically we can extend it in whichever we want and we can also customize it the unit test yeah I mean we have some unit tests the library in Volto and these are basically some of the commands which we use and some of the tests we already had in Volto Co I'll be talking about how we extend these tests and how do we use that test in add-ons later so this are just the basic commands which we use in Volto to test and basically we on the back on the on the back so basically Volto on the back and it's used the results so we just call that result test the results along with some along with some involvement variables like the just which test the which runs the test in the JS DOM involvement and also we have some other commands there and this like we have for the testing we have the configuration so every every just it expects some configuration either from the package JSON object and or the just configured JSON file so this is just the basic configuration mode we have in Volto and it's pointing to the global set of files and it's more actually so it's just a part of it and also we can override this with the result just config so if a developer he wants to have a its own just config then he can use that in the variable and he can override that config with the I mean with the add-on and on config so this is an environment we generally use it I'll explain about like where to use that and now we just like like it's just a sample test when we write it I mean is a simple test unit test file it's a test for logo and we import some functions from the like famous testing libraries a react test render and some like store mock so we have so there are some components we need to test it and generally we use two types of testing one is we use more snapshot test which really test how that component renders into the DOM and the DOM structure of that component changes then it filled the test so it's it's it's it's it's the the view view view ability of that add-on and that's the other thing is we test the functionality of that component we use several sessions for that so this one is the basic test which creates a snapshot actually and we have a mock store for it so mock store what it does is the components which are under the redux tree they they should be exposed to the redux store so we just are creating a new redux store and we are wrapping the component into that store so that the store is available inside that component and basically renders the logo component checks if that component renders and the if that component has last change according to the snapshot so yeah so this is the snapshot testing basically which we use in in many of our component tests so I think like almost every component in a world I think it's snapshot tested especially when it comes to view layers so we have this this is a sample component so we have found so this is how we just write the test so it's found or test or just and it so it imports the render library from react test render and render will create a component component tree and then it convert that component into a JSON so that that's how we basically calculate the diff so it automatically when we convert that component to a JSON it will create that creates the snapshot and it calculate that if that component there's drum structure which usually changes so if that change then that snapshot will fail and this is the this is how the snaps are generated so on the first test the snaps are generated and if we change let's say if we change that a link to plon dot org from plon dot org to some let's say a Twitter or something then that snapshot will fail and then we have to decide if you want to update that snapshot or not if you want to update it then we can update it we are just updating snapshot flag so just has this view minus minus you flag which updates the snapshot and then there's basically that as passes yeah we have some assertions in the testing I mean so these are basically the general testing infrastructure which every front end project should have and you have this react testing library in Volto and in Volto add-ons as well so we use this testing library heavily I mean a lot to create a session so this is a basically a photo test and like so this we import the render from the react testing library and we like I said earlier we also create a smoke store for it and what the render function from react testing library does is it creates that component tree and it injects that component whole into a document body so that we can make a sessions on it and there also it also provides several other functions like we can like see what what what what is the particular test on the screen and what we can we can have several should we can also have several matches and it's just a simple container and it checks if it's have the text content thrown in it so it's indexed in so what render does is it injects that component to a DOM and just give the sessions yeah we can have more sessions I mean we can more we can have more matches in paper I just matches and it's available via this testing library just DOM like we have the external except expect we import it we just need to import it and we can just add more accessions to our test yeah so let's talk about Cypress so it's basically it's my favorites and how it handles the end to end test we rely heavily on like end to end test in Walto because it's creates like it's it's knows the breaking part of or breaking the part of the components code how which part of that component is breaking it and where it breaks it so yeah the so this is very like a nice tool so I call it is a regress and repeatable end to end testing tool and this is a definition from the Cypress IO website is a testing tool and it is written in JavaScript and help developers write automatic test for the web so like there are some like challenges for this test I mean like when we write a unit when we write end to end test now we moved from unit test to end to end test so these are some challenges which we face when we move from like when we move towards the end to end test so first challenge is the selectors and match so it's basically a difficult thing to like to identify which selectors and the specificity specificity of that selector because a same selector can have that I mean the same element can have to like a class can have used by two elements and so it's basically we need to be specific so these are the some challenges regarding the selectors and also some we have a sink and mutual dependent events so like if we have a sink events which depends on another like finishing of the other event then we need to make sure that the other event finishes first then for the mutual dependent events it's also quite tricky to like quite tricky to think about so we have data manipulation is hard like when we use the when we write Cypress Chasin when then we'll have to add some fixtures so fixtures basically are something which we which we currently use to mock the data basically we supply the mock data and we'll talk about in the future I mean the later test slides so we have the we should have the consistent consistent test environments yeah that's why we it's it's it's advice to run this test in the Docker container so like so so that we have the consistent test environment otherwise generally we in pro-holder projects we work with the Raziel API and the Raziel API path is like can be different for different projects so it's like the consistent test environment setup is quite important for like for having the best writing test writing experiences and yeah so it's also adaptation to UI changes because if we change something the DOM then the then then the selector will change and eventually the test will fail so we have to adapt to UI changes and the challenges yeah and then we have selectors so selectors I think they are the basic that they are the basic building blocks I would say they are the basic building block of a test so so like this is how you will like a test in Cypress you will you will just use the CI.txt and this is this is just a normal CSS selector you can use any of the selector here and and like using this selector we should make we have these accessions here so cy.cat username should have the text joe smith so it basically checks if that like username element with the id username they have the text smith or not so these are just the basic accessions and we basically heavily rely on it if we want to write a Cypress test and this is the basic configuration file so Cypress expects configuration JSON file in the root and we usually specify the base URL the report width and the other things we can also specify screenshots so there are a bunch of options it's available in the Cypress documentation and you can look at it yeah so like as I said like I will give the demo later on so as I said the Cypress is basically it's a tool how do we like how do we replicate what we generally work on so for Cypress we need to start the backend and then we need to start the front end as well and then only we can write the Cypress because it's unlike the net test it will check the whole workflow of the application so we need to make sure we need to have these commands and these commands working properly and this is the structure of the typical Cypress suite so if we go to Cypress we have these pictures where we store that example data where we want to get the API from and this is an example API data and in the integration generally we have this test so like integration slash example slash we we can have different tests here for the different different modules and then we have a separate support and the next module so this is how the structure typical structure looks yeah so commands basically we use few Cypress commands to run these Cypress tests the difference between these two commands is Cypress run it runs that just runs the whole the test without opening the browser basically runs that test in the headless mode and Cypress open is opens that browser and runs that in headed mode with automated like tool that operating operates the browser and we also can show the we can also show these screens store the screenshots and videos it's it also come in handy when in debugging so I'll come to later later that part how to debug that code we have custom commands in Cypress so so like we can write on custom command custom commands so that we can don't we don't need to rewrite that code and we can just use that code wherever we want so they are some custom custom commands which are stored in that commands file and we can just add that command so it's just adding the login command and below that it's like it's written what that that command does is so basically it requests to the post I mean the login URL and it just returns that thing and then if you want to use it then we can use it see what login anywhere in our project we don't need to write that command again so this this command generally comes in handy when writing this yeah we can also make it modular so it's like we can have the page title let's let's say we have some smaller functions we can put it into a different helper and then we can just call that method with this let's say we want to change the page title we make that method just like in in any other frontal project in Vol2 we have helper method we can also help add some helper methods in the Cypress infrastructure now we can also this is the best part which I have seen I love in Cypress so we can intercept the request basically so this is how generally we make requests to follow our path so we can intercept the request by modifying its properties and body and whatever we want so let's say if you want to add a if you want to show the error from back end so we will intercept that request we'll change whatever you want to do we don't need to create another I mean we don't need to follow the original request we'll create our own request so we'll intercept that request we'll tell okay we don't want that request and we'll just show that customer custom error message and then we'll wait for that request to happen and then if it's intercepted then we'll we can make a sessions on it we can do whatever you want debugging also it's a like debugging is also awesome thing which we generally like love in Vol2 so I mean love in Cypress when we writing when we are writing the Cypress test for Vol2 so like six we have we for debugging we do have Cypress screenshots and videos which generally help but we also have a like another debugging API in Cypress so we have debug and we so what debug does it just sets the console breakpoint and we can now like click on the debug and then we will let's see what the debug what that subject particular element have element is having so this is how that debug function works like the add-ons now like so basically let's so this is this is not the general how we like test writes test in Cypress now if we move to add-ons so yeah everyone knows about add-ons is just basically more control extending its powers so it's basically give more powers to Vol2 so what about testing add-ons so like we do have this Vol2 add-ons CI which that creates a projects for us and it forks then add-on and then it runs the testing inside the Docker container so like as I said that we have we should run this test inside inside the Docker container because it should have the consistent test environment that's why generally we have that test inside the Docker container and we use this Vol2 add-on CI tool for that so so Vol2 add-on CI it's basically it's just the Docker I mean Docker container which has two commands so basically so one is we can run it by a CI and we'll need to I mean pull it and then we can run the container, spin the container up and then we can pass that our name of the add-on and the test what test we want to run it I'll come to that later how that will work so otherwise if you want to develop it locally then we can also run the test with a local so a local bind mount like for the local we need to mount our own local directed inside the Docker container so that's why so basically it copies that director inside the Docker container and then we can for local we can run the tests as well so this is how Vol2 scaring and then Vol2 add-on CI it basically so it does everything basically so it's just one command and say like in place of this command name you can have several other commands as well so if you use test then we can run just test Vol2 add-ons I mean the unit test in Vol2 add-ons if we have the ES link then we can we can have the we can run these ES link checks and we can have styling we can have styling check and we can prettier and we also have a Cypress and run the Cypress in the run mode so Vol2 does this and if we don't want to use Docker then you can like always run it like on your local so just start on container on the back end and start front-end and these two things are necessary and then start writing test with the arms that is open so if I like just let's give you the demo okay I have a YouTube link let's go through the test if you can see the screen now so this is basically how do we like write test in Cypress so I just wanted to show you this are this test are running via my local and basically what this is this is this is a browser which is controlled by automated tool and it turns that the Cypress test and the good thing about Cypress is if we if we stop it and if we can time travel it we can see what the content it has and we can also like if we go to my add-on page if you if you go to type if you click on it then you will have this a diff screenshot so we snapshot of the test so we can see the diff tool after see if we can see what the content has changed in that particular element so this thing which I really loves about Cypress it really focuses on the the snapshot on a debugging part so you can also like inspect that element from here only like if you inspect it then on the console also you'll have information about that page type so if you see the command and you have this the element which it disposes and you can see and you can just have that you can get that selector and then you can work with it so this is how like current we can also press a debugger into the code and it also like at the debug at this point it will create a breakpoint and start debugging so and these are screenshots if you want you can save it in your local file as well and that will also come in handy if I debug in and I like if you want to run the test again so that's how basically Cypress like runs and it just kind of like used by an automated tool and the automated tool controls the headless browser and it just runs everything we don't need to just do anything and that's the test out of that's I think the beauty of Cypress and it's running without the I mean on my local container so that's how it works another thing I talk about the running is yeah the bonus tip is like we have a coromax extension for writing that test so we have Cypress recorder which record test for us so we don't need to go to I mean don't need to inspect the element we don't need to find that element we just we can use that Cypress recorder and we can just grab that selector for the projector but it's always good to cross check that but yeah it'll come in handy if you use it so it's just a Chrome extension it's available so just it's a good tip yeah thank you thank you for presenting that was really great I love seeing the testing infrastructure in the tooling that we can use for ensuring high quality software components so thank you very
 Hi, welcome back to Plum Conference 2021, Track 1. We are here with Nailesh and he is  going to be talking to us about testing Volto add-ons and the testing infrastructure.  Hello there, thanks, Andy, for the introduction. I hope you can hear me. So a little bit about  me, I started contributing to Plum Volto since 2018 when I started as a Google  someone of course student and now it's been almost two and a half years and I  started contributing to Volto Core as an individual contributor and now currently  I work as a front-end developer at other web and since two years Volto has  been like evolved a lot when it comes to the extensibility story, the theming, the  development workflow and like add-ons and the blocks especially so everything. So  this talk will be more about the add-ons like the testing and add-ons like how  was the testing infrastructure evolved in Volto and how did we  extended that to further add-ons. So let's talk about it. So like Volto we have a  generic text setup here like so we do a three-bunch testing in Volto like the  unit tests and the integration test and the end-to-end test. So first unit test  is just basic unit tests which are basically return we are just the  just is basically a test runner which runs and they also provide some out-of-the-box  accession tools for us. So another thing another tool we use for unit testing is  React testing library so it provides us out-of-the-box tools for these snapshots  and for the more or less the accession way of testing writing the unit test.  So basically unit tests are the important part of our code. It basically  validates what a developer is writing. So like we aim to have like above 90%  coverage but yeah I mean the unit tests basically are the very important  thing in our in Volto in every front-end code and then next is we have  the integration testing like in integration we have CI right now we I  think move to meta workflows and actions and before we used to have this Jenkins  and like Travis and also we run these tests on like everything in the just  Cypress and every link in the CI and the other thing which I really love is the  end-to-end testing we heavily rely on Cypress for it so Cypress is a tool which  does the end-to-end test for our add-ons or for our projects or whatever it is.  So like it validates what a user has written and it just text end-to-end  workflow and applications from start to end and whether the code  return has some flaws or whether the feature is working or not so it's  basically a Cypress which does the magic so it's basically fully controlled by  automated software and runs using a headless browser so I will talk about it  more we will go into a little bit depth about the Cypress mainly and how they  testing is how the tools what are the tools we use in Volto. So like what's  the like motivation behind like why do we need to test I mean we the  Volto code because it helps to reflect our add-on to a better design so we  tested it rigorously and we write unit test write the acceptance test for it  and we can you know we know that what part of the add-on is breaking and what  part does work well so that's why it's helped to we can adhere to good guidelines  of the research the testing guidelines so that we can know the breaking parts in  Volto the add-ons the second I think is yeah I mean we as I said earlier we have  already matured set up in Volto and we would like to you reuse that setup in  from Volto we extend that setup to add-ons so we have several tools for  that and it's basically these the extension they are basically the  custom customizable so we can customize it we can override these and so we are  just making the use of the older which the setup we have to we have already  involved this also saves the developers time and also yeah the test  they run in CI and is the same as the local so this local and the CI they are  they run one the same so it's not like a developer point of view not  kind it doesn't create any separation developers perspective and also like as  I said we have the end-to-end test which which are really I would say the checks  the authenticity or the the vulnerability within our add-ons so if so it  checks the from start to end the every single component of an add-ons and it  also shows in shows that the add-ons which have the add-ons should have the  stronger connectivity because we have many projects that we have different add-on  we have multiple add-ons I think 20 30 add-ons and we need we don't know which  add-ons is it dependent on another add-on that's why that's how the end-to-end test  comes in handy so it automatically identifies which add-ons has another  add-on dependent and we can identify them and yeah it's adaptable to needs so  basically the testing they are basically we can extend it in whichever we want  and we can also customize it the unit test yeah I mean we have some unit tests  the library in Volto and these are basically some of the commands which we  use and some of the tests we already had in Volto Co I'll be talking about how we  extend these tests and how do we use that test in add-ons later so this are just  the basic commands which we use in Volto to test and basically we on the  back on the on the back so basically Volto on the back and it's used the  results so we just call that result test the results along with some  along with some involvement variables like the just which test the which runs  the test in the JS DOM involvement and also we have some other commands there  and this like we have for the testing we have the configuration so every every  just it expects some configuration either from the package JSON object and or  the just configured JSON file so this is just the basic configuration mode we  have in Volto and it's pointing to the global set of files and it's more  actually so it's just a part of it and also we can override this with the result  just config so if a developer he wants to have a its own just  config then he can use that in the variable and he can override that config  with the I mean with the add-on and on config so this is an environment  we generally use it I'll explain about like where to use that and now we just  like like it's just a sample test when we write it I mean is a simple test unit  test file it's a test for logo and we import some functions from the like  famous testing libraries a react test render and some like store mock so we have  so there are some components we need to test it and generally we use two types  of testing one is we use more snapshot test which really test how that component  renders into the DOM and the DOM structure of that component changes then it  filled the test so it's it's it's it's it's the the view view view ability of that add-on  and that's the other thing is we test the functionality of that component we use  several sessions for that so this one is the basic test which creates a snapshot  actually and we have a mock store for it so mock store what it does is the  components which are under the redux tree they they should be exposed to the  redux store so we just are creating a new redux store and we are wrapping the  component into that store so that the store is available inside that component  and basically renders the logo component checks if that component renders and the  if that component has last change according to the snapshot so yeah so this  is the snapshot testing basically which we use in in many of our component  tests so I think like almost every component in a world I think it's  snapshot tested especially when it comes to view layers so we have this this is  a sample component so we have found so this is how we just write the test so  it's found or test or just and it so it imports the render library from react  test render and render will create a component component tree and then it  convert that component into a JSON so that that's how we basically calculate  the diff so it automatically when we convert that component to a JSON it will  create that creates the snapshot and it calculate that if that component there's  drum structure which usually changes so if that change then that snapshot will  fail and this is the this is how the snaps are generated so on the first test  the snaps are generated and if we change let's say if we change that a link to  plon dot org from plon dot org to some let's say a Twitter or something then  that snapshot will fail and then we have to decide if you want to update that  snapshot or not if you want to update it then we can update it we are just  updating snapshot flag so just has this view minus minus you flag which updates  the snapshot and then there's basically that as passes yeah we have some  assertions in the testing I mean so these are basically the general testing  infrastructure which every front end project should have and you have this  react testing library in Volto and in Volto add-ons as well so we use this  testing library heavily I mean a lot to create a session so this is a basically  a photo test and like so this we import the render from the react testing  library and we like I said earlier we also create a smoke store for it and  what the render function from react testing library does is it creates that  component tree and it injects that component whole into a document body so  that we can make a sessions on it and there also it also provides several  other functions like we can like see what what what what is the particular test  on the screen and what we can we can have several should we can also have  several matches and it's just a simple container and it checks if it's have the  text content thrown in it so it's indexed in so what render does is it  injects that component to a DOM and just give the sessions yeah we can have more  sessions I mean we can more we can have more matches in paper I just matches and  it's available via this testing library just DOM like we have the external  except expect we import it we just need to import it and we can just add more  accessions to our test yeah so let's talk about Cypress so it's basically it's  my favorites and how it handles the end to end test we rely heavily on like end  to end test in Walto because it's creates like it's it's knows the breaking part of  or breaking the part of the components code how which part of that component is  breaking it and where it breaks it so yeah the so this is very like a nice  tool so I call it is a regress and repeatable end to end testing tool and  this is a definition from the Cypress IO website is a testing tool and it is written  in JavaScript and help developers write automatic test for the web so like there  are some like challenges for this test I mean like when we write a unit when we  write end to end test now we moved from unit test to end to end test so these  are some challenges which we face when we move from like when we move towards the  end to end test so first challenge is the selectors and match so it's basically  a difficult thing to like to identify which selectors and the specificity  specificity of that selector because a same selector can have that I mean the  same element can have to like a class can have used by two elements and so it's  basically we need to be specific so these are the some challenges regarding the  selectors and also some we have a sink and mutual dependent events so like if we  have a sink events which depends on another like finishing of the other  event then we need to make sure that the other event finishes first then for the  mutual dependent events it's also quite tricky to like quite tricky to think  about so we have data manipulation is hard like when we use the when we write  Cypress Chasin when then we'll have to add some fixtures so fixtures basically are  something which we which we currently use to mock the data basically we supply  the mock data and we'll talk about in the future I mean the later  test slides so we have the we should have the consistent  consistent test environments yeah that's why we it's it's it's advice to run this  test in the Docker container so like so so that we have the consistent test  environment otherwise generally we in pro-holder projects we work with the  Raziel API and the Raziel API path is like can be different for different  projects so it's like the consistent test environment setup is quite important  for like for having the best writing test writing experiences and yeah so it's  also adaptation to UI changes because if we change something the DOM then the  then then the selector will change and eventually the test will fail so we have  to adapt to UI changes and the challenges yeah and then we have selectors so  selectors I think they are the basic that they are the basic building blocks I  would say they are the basic building block of a test so so like this is how  you will like a test in Cypress you will you will just use the CI.txt and this is  this is just a normal CSS selector you can use any of the selector here and and  like using this selector we should make we have these accessions here so  cy.cat username should have the text joe smith so it basically checks if that like  username element with the id username they have the text smith or not so these  are just the basic accessions and we basically heavily rely on it if we want  to write a Cypress test and this is the basic configuration file so Cypress  expects configuration JSON file in the root and we usually specify the base URL  the report width and the other things we can also specify screenshots so there  are a bunch of options it's available in the Cypress documentation and you can  look at it yeah so like as I said like I will give the demo later on so as I said  the Cypress is basically it's a tool how do we like how do we replicate what  we generally work on so for Cypress we need to start the backend and then we  need to start the front end as well and then only we can write the Cypress  because it's unlike the net test it will check the whole workflow of the  application so we need to make sure we need to have these commands and these  commands working properly and this is the structure of the typical Cypress  suite so if we go to Cypress we have these pictures where we store that example  data where we want to get the API from and this is an example API data and in  the integration generally we have this test so like integration slash example  slash we we can have different tests here for the different different modules and  then we have a separate support and the next module so this is how the  structure typical structure looks yeah so commands basically we use few Cypress  commands to run these Cypress tests the difference between these two commands  is Cypress run it runs that just runs the whole the test without opening the  browser basically runs that test in the headless mode and Cypress open is opens  that browser and runs that in headed mode with automated like tool that  operating operates the browser and we also can show the we can also show these  screens store the screenshots and videos it's it also come in handy when in  debugging so I'll come to later later that part how to debug that code we have  custom commands in Cypress so so like we can write on custom command custom  commands so that we can don't we don't need to rewrite that code and we can  just use that code wherever we want so they are some custom custom commands  which are stored in that commands file and we can just add that command so it's  just adding the login command and below that it's like it's written what that  that command does is so basically it requests to the post I mean the login  URL and it just returns that thing and then if you want to use it then we can  use it see what login anywhere in our project we don't need to write that  command again so this this command generally comes in handy when writing  this yeah we can also make it modular so it's like we can have the page title  let's let's say we have some smaller functions we can put it into a different  helper and then we can just call that method with this let's say we want to  change the page title we make that method just like in in any other frontal  project in Vol2 we have helper method we can also help add some helper methods  in the Cypress infrastructure  now we can also this is the best part which I have seen I love in Cypress so  we can intercept the request basically so this is how generally we make requests  to follow our path so we can intercept the request by modifying its properties  and body and whatever we want so let's say if you want to add a if you want to  show the error from back end so we will intercept that request we'll change  whatever you want to do we don't need to create another I mean we don't need to  follow the original request we'll create our own request so we'll intercept that  request we'll tell okay we don't want that request and we'll just show that  customer custom error message and then we'll wait for that request to happen  and then if it's intercepted then we'll we can make a sessions on it we can do  whatever you want debugging also it's a like debugging is also awesome thing  which we generally like love in Vol2 so I mean love in Cypress when we  writing when we are writing the Cypress test for Vol2 so like six we have we for  debugging we do have Cypress screenshots and videos which generally help but we  also have a like another debugging API in Cypress so we have debug and we so what  debug does it just sets the console breakpoint and we can now like click on  the debug and then we will let's see what the debug what that subject  particular element have element is having so this is how that debug function  works like the add-ons now like so basically let's so this is this is not  the general how we like test writes test in Cypress now if we move to add-ons so  yeah everyone knows about add-ons is just basically more control extending its  powers so it's basically give more powers to Vol2 so what about testing add-ons so  like we do have this Vol2 add-ons CI which that creates a projects for us and  it forks then add-on and then it runs the testing inside the Docker container so  like as I said that we have we should run this test inside inside the Docker  container because it should have the consistent test environment that's why  generally we have that test inside the Docker container and we use this  Vol2 add-on CI tool for that so so Vol2 add-on CI it's basically it's just  the Docker I mean Docker container which has two commands so basically so one is  we can run it by a CI and we'll need to I mean pull it and then we can  run the container, spin the container up and then we can pass that our name of  the add-on and the test what test we want to run it I'll come to that later  how that will work so otherwise if you want to develop it locally then we can  also run the test with a local so a local bind mount like for the local we  need to mount our own local directed inside the Docker container so  that's why so basically it copies that director inside the Docker container and  then we can for local we can run the tests as well so this is how Vol2  scaring and then Vol2 add-on CI it basically so it does everything basically  so it's just one command and say like in place of this command name you can have  several other commands as well so if you use test then we can run just test  Vol2 add-ons I mean the unit test in Vol2 add-ons if we have the ES link then we  can we can have the we can run these ES link checks and we can have styling we  can have styling check and we can prettier and we also have a Cypress and  run the Cypress in the run mode so Vol2 does this and if we don't want to use  Docker then you can like always run it like on your local so just start on  container on the back end and start front-end and these two things are  necessary and then start writing test with the arms that is open so if I like  just let's give you the demo okay I have a YouTube link let's go through the test  if you can see the screen now so this is basically how do we like write test in  Cypress so I just wanted to show you this are this test are running via my local  and basically what this is this is this is a browser which is controlled by  automated tool and it turns that the Cypress test and the good thing about  Cypress is if we if we stop it and if we can time travel it we can see what the  content it has and we can also like if we go to my add-on page if you if you go  to type if you click on it then you will have this a diff screenshot so we  snapshot of the test so we can see the diff tool after see if we can see what  the content has changed in that particular element so this thing which I  really loves about Cypress it really focuses on the the snapshot on a  debugging part so you can also like inspect that element from here only  like if you inspect it then on the console also you'll have information  about that page type so if you see the command and you have this the element  which it disposes and you can see and you can just have that you can get that  selector and then you can work with it so this is how like current we can also  press a debugger into the code and it also like at the debug at this point it  will create a breakpoint and start debugging so and these are screenshots if  you want you can save it in your local file as well and that will also come in  handy if I debug in and I like if you want to run the test again so that's how  basically Cypress like runs and it just kind of like used by an automated tool  and the automated tool controls the headless browser and it just runs  everything we don't need to just do anything and that's the test out of  that's I think the beauty of Cypress and it's running without the  I mean on my local container so that's how it works  another thing I talk about the running is yeah the bonus tip is like we have a  coromax extension for writing that test so we have Cypress recorder which record  test for us so we don't need to go to I mean don't need to inspect the element  we don't need to find that element we just we can use that Cypress recorder and  we can just grab that selector for the projector but it's always good to cross  check that but yeah it'll come in handy if you use it so it's just a  Chrome extension it's available so just it's a good tip yeah thank you  thank you for presenting that was really great I love seeing the testing  infrastructure in the tooling that we can use for ensuring high quality software  components so thank you very
Testing_Volto_Addons_-_Nilesh_Gulia_4CKTlDq3mXQ_0_5651.png Testing_Volto_Addons_-_Nilesh_Gulia_4CKTlDq3mXQ_5652_16643.png Testing_Volto_Addons_-_Nilesh_Gulia_4CKTlDq3mXQ_16644_19079.png Testing_Volto_Addons_-_Nilesh_Gulia_4CKTlDq3mXQ_19080_20135.png Testing_Volto_Addons_-_Nilesh_Gulia_4CKTlDq3mXQ_20136_20351.png Testing_Volto_Addons_-_Nilesh_Gulia_4CKTlDq3mXQ_20352_21779.png Testing_Volto_Addons_-_Nilesh_Gulia_4CKTlDq3mXQ_21780_21827.png Testing_Volto_Addons_-_Nilesh_Gulia_4CKTlDq3mXQ_21828_21935.png Testing_Volto_Addons_-_Nilesh_Gulia_4CKTlDq3mXQ_21936_22103.png Testing_Volto_Addons_-_Nilesh_Gulia_4CKTlDq3mXQ_22104_22175.png Testing_Volto_Addons_-_Nilesh_Gulia_4CKTlDq3mXQ_22176_22631.png Testing_Volto_Addons_-_Nilesh_Gulia_4CKTlDq3mXQ_22632_22679.png Testing_Volto_Addons_-_Nilesh_Gulia_4CKTlDq3mXQ_22680_25427.png Testing_Volto_Addons_-_Nilesh_Gulia_4CKTlDq3mXQ_25428_26135.png Testing_Volto_Addons_-_Nilesh_Gulia_4CKTlDq3mXQ_26136_26219.png Testing_Volto_Addons_-_Nilesh_Gulia_4CKTlDq3mXQ_26220_26279.png Testing_Volto_Addons_-_Nilesh_Gulia_4CKTlDq3mXQ_26280_28007.png Testing_Volto_Addons_-_Nilesh_Gulia_4CKTlDq3mXQ_28008_32963.png Testing_Volto_Addons_-_Nilesh_Gulia_4CKTlDq3mXQ_32964_36527.png Testing_Volto_Addons_-_Nilesh_Gulia_4CKTlDq3mXQ_36528_37007.png Testing_Volto_Addons_-_Nilesh_Gulia_4CKTlDq3mXQ_37008_37127.png Testing_Volto_Addons_-_Nilesh_Gulia_4CKTlDq3mXQ_37128_37175.png Testing_Volto_Addons_-_Nilesh_Gulia_4CKTlDq3mXQ_37176_37235.png Testing_Volto_Addons_-_Nilesh_Gulia_4CKTlDq3mXQ_37236_37475.png Testing_Volto_Addons_-_Nilesh_Gulia_4CKTlDq3mXQ_37476_37571.png Testing_Volto_Addons_-_Nilesh_Gulia_4CKTlDq3mXQ_37572_37919.png Testing_Volto_Addons_-_Nilesh_Gulia_4CKTlDq3mXQ_37920_40163.png Testing_Volto_Addons_-_Nilesh_Gulia_4CKTlDq3mXQ_40164_40379.png Testing_Volto_Addons_-_Nilesh_Gulia_4CKTlDq3mXQ_40380_40499.png Testing_Volto_Addons_-_Nilesh_Gulia_4CKTlDq3mXQ_40500_40655.png Testing_Volto_Addons_-_Nilesh_Gulia_4CKTlDq3mXQ_40656_40763.png Testing_Volto_Addons_-_Nilesh_Gulia_4CKTlDq3mXQ_40764_40895.png Testing_Volto_Addons_-_Nilesh_Gulia_4CKTlDq3mXQ_40896_41747.png Testing_Volto_Addons_-_Nilesh_Gulia_4CKTlDq3mXQ_41748_42155.png Testing_Volto_Addons_-_Nilesh_Gulia_4CKTlDq3mXQ_42156_42192.png