#3. Exploring the Cypress Real World App by Cecelia Martinez - Cypress.io UK Community - July 15

[Music] to learn more about Cyprus best practices and to take those and into your own applications and your own test Suites so the github repository for the applicant for this app is at Cypress io / Cypress real world app and so this is their actual github repository where you can see all the code you can clone it and you can pull it down to get it installed all right and then just so you can get started so like I said I'm Cecilia I'm a success engineer at Cypress I've been there since January I'm from Atlanta well I'm in Atlanta from all over here now love it love the city I do some volunteer work I am a track evangelist for a woman who code front end and I'm also on the leadership team for out in tech which supports lgbtqia+ people in the tech industry and I started the helped found the Atlanta chapter about in tech you can find me online on Twitter github at Cecilia creates a usually the best way to find me in general on Twitter on github if you do have any questions about the real world app please feel free to create issues in the app it's you know it is open-source it's meant to be a collaborative tool for everyone to use and you can also always reach me on Twitter if you have anything specific as well okay so why the real-world app you know why does Cypress go ahead and and make this application so it was essentially designed to showcase real-world usage of Cypress testing methods patterns and workflows it is a payment application similar to venmo pass at PayPal essentially where you can send and receive transactions to friends and then also add bank accounts update your profile authentication a lot of the same functionality that exists in applications that you see in production it was designed to be able to clone install and run the app without needing any additional dependencies are native components it's meant to help you get up and running quickly and seeing how ciphers works in the real world and like I said it's meant to allow you to learn experiment tinker and practice using Cypress and different applications of ways that you can use it so Murray did mention the tech stack so we're going to dive into that next the real-world app is built with react on the front end it uses a library called X State to manage the state of the application so rather than using something like a root like redux or a different type of data store we're using an X State to manage that in the front-end of our application it does have an express back-end that handles the API and the database is managed with low DB it's essentially a library that allows us to utilize a flat file JSON database that way and there and the reason for that again is that you don't have to build up your own database in order to run the application the we're using the material UI component library for the design and then it also does use typescript so if your application uses typescript you can see how to test a typescript application with Cypress and what that entails and we'll definitely be talking a little bit about that as well so the app functionality it does a lot of different things like I said it's similar to this is what it looks like when you log in it's similar to a venmo cache app where essentially you have bank accounts that you add you can search for friends and you can create transactions so if we take a look at what the app can do and how it's similar to a lot of real-world production applications you have the same similar kind of challenges that you would experience you have the authentication you know making sure that the user can sign up log in and log out you have onboarding making sure they're able to initially get set up with the app create their profile and whatever steps need to be done in order to get them set up you add and delete bank accounts create transactions accept or reject transaction requests you can like and comment on transactions you can view transactions between friends different different categories of transactions you can update your profile and you can also view and dismiss notifications so we're going to talk a lot about all the different functionality and what that looks like in the app and ways that you can test for this so rather than click through everything and show you I wanted to essentially we generated this demo video using the Cypress movie plugin it is available at the repository here the way that it works is essentially it's a way to leverage Cypress to do product demos or to demonstrate applications by automatically running through the functionality so that is what this video is so we can take a look and see here maybe we can make it fullscreen so it's mostly visible but so the application allows you to sign up a user so it goes through a normal essentially signup process that looks very familiar you can then log in it goes through the user onboarding so with the onboarding you create a bank account initially and you get set up it allows you to add additional bank accounts if you need to and again these are not real bank accounts don't really users not those transactions it's about to be dumped demonstrative you can delete bank accounts and then this is kind of the the medius part of the app that the as somebody a new transaction this is the main functionality and confirming that the transactions have gone through like I said before you can accept requests and you can also reject transaction requests and then you can react to transaction so you can like and you can add comments and then you can view transactions from your everyone friends and also personal transactions you couldn't update your profile and you can view and dismiss notifications just like how you would in a lot of different applications and of course you can log out so those are the core functions of the application and what that looks like and again this was generated with Cypress movie plugin what this does is it slows down the speed of the test runs that you can read see everything that's going on it also allows adds an extra commands that removes the the command log so you don't see the tests running on the side and then it also gives you that functionality to add the toast in the bottom and add the arrows that we have that you saw throughout the demo video so definitely recommend also checking that out it is it's also open source and so please feel free to create any issues on that repository and that's also included here this link and the application so that goes to the repo here Cypress movie alright so that's what the application does let's talk about how it's the what the code looks like so next we're going to talk we're going to be going through the installation file organization configuration and then you know actually using the application what you would need to get it set up so like we said we wanted to it to be as simple and easy as possible to be able to clone install and run this app so once you clone the repository from github you know you can just kind of pull it down using SSH irritable HTTPS and then you just run yarn install then you run yarn dev and this actually starts up the application and then in a new terminal you would runs yarn Cypress open to open the test Runner and then once the test runner is open and see how they were taking a look at the file organization a couple of things I wanted to point out so in our Cypress JSON folder the way that normally whenever you install Cypress the default test folder is in is called integration it's your integration folder that's where all the tests are held in this case because we have both UI and API tests the folder integration folder isn't that name is a quick make as much sense so it's changed to tests so we do have to designate that our integration folder is Cypress slash tests you don't have to do this it's already been done I just wanted to point it out because you may have a similar situation where you have a different name for your test folder and this is how you would update that and so the folder structure within the cypress is has you know looks pretty similar in for familiar with Cypress already you have your fixtures your plugins your support folder which contains your commands your index file and then also we have some utilities and then we have our test folder which contains the API and the UI so to give this a look in the S code here I have this the as big as possible so we can see that we have within our Cypress folder our fixtures this is as a result of Cypress movie we have our plugins our support and then our tests and within our tests we have our API tests and our UI tests and I just see a question about NPM so this this says where you use use yarn you can still start cypress using npx cypress however yarn allows you to just kind of get started and running really quickly so Cypress that JSON the configuration folder a file again you don't have to make any changes here again you can just pull on the repo yarn install yarn dev and start using the application but I do want to point out some things here that may be helpful in your own projects and just show what's working behind the scenes so we do have our in our base you are set up this is a best practice across all cypress projects is to designate the URL where your application is running so you don't have to type it in annually across your app you guys mentioned before we've reset our integration folder to be Cypress slash tests and then we also have the API URL for our back-end this is a localhost 3001 so when you run yarn Deb it starts the front and back another application all with one command and this is how we designate where those two parts of our application are running so I did want to also mention this applet this app is built with typescript so we do have to add types for any kind of custom commands that we run in Cypress there is a global DTS file within the Cypress folder that contains all of the types this is just a subset of some of them but I wanted to showcase these there are three different types of custom login commands and we can see with what it looks like when we are defining the types for typescript so in this case the parameters that are being accepted for login by API is a user name which is a string it may also contain a password which would be a string and then ascend it returns a response login by ex-state again a username that's a string may contain a password that's a string and that is a return of any type and then logout by X date does not have any parameter types and then it just returns void because it doesn't have an actual return value so again going back into vs code we can see in our global that the DTS file that's tough to say that this is where we define any and all of our custom command types for Cypress so if you need to leverage custom commands within your own typescript application this is an example of how you could essentially define those so again we have our login by API and then we do have some additional scripts in the package.json that I wanted to point out so if you did want to start the application not in watch mode so if you wanted to start it but you're not really making any changes you can just run yarn start there's also a DB seed command which will seed your database this command actually runs every to automatically every time you start the application and also in between every test and we'll be talking a lot about the data management of this application so start empty is if you wanted to start the application with no database seeding so this would essentially start it without any of that data in place and then list dev users is a command that essentially shows the user names that you can use to login the application speaking of logging in there is a user list in data slash database JSON or database C JSON if you have never actually run the application then you won't have a database that's been seeded yet but you can get that data from database seed this will show all the usernames that you can use to log in the default password for everyone is secret with a three and we can see that here in our data so we have our database seed that JSON here that contains all of our users ok so we talked about the about why the app exists we talked a little bit about the file structure the organization and getting started with it I want to spend a good amount of time talking about the testing approach because the purpose of this application is to show best practices and a lot of those best practices are represented and how we decided to organize the structure our tests and how we decided to manage the data the application so the real-world app does have API UI and unit tests the API and the UI tests are both managed by Cypress and then the unit tests are run ingest so for the API tests API tests were helpful in validating the backend before building the front-end as we were developing this application or ask that our developer experience team was developing this application and API tests with Cypress don't always make sense it depends on when you're running the tests in this case because we're already spinning up a browser to to run the UI tests we can use Cypress for the API tests as well and we also want to demonstrate what this looks like because we do get questions or people who ask we can use ciphers for API testing and this is how you essentially would do that in real life so the use of signup requests to make requests and then make assertions on the response and like I said it makes sense to use ciphers for API tests in this case because we're spitting up a browser anyway so what it looks like I'm going to kind of show here for the API tests if we take a look at a bank account it looked pretty straightforward so essentially we have a context for each of our come about request types and then we also have the endpoint essentially it's making a sign-up request to that endpoint with the request type and then it's just making assertions on the response so for example in this case we wanted to get a list of bank accounts for the user it's making a call to that API endpoint and then it's the response we're asserting that the status came through correctly and that the body is equal to the the user ID is equal to the user ID that we are expecting so this is this the function in the format for using Cypress for API testing and again this is just a kind of a more of a specific breakdown so like we said we get say uselessly the user bank accounts makes the request at the endpoint and then it makes an assertion on the response the UI tests they're designed around the user views of the application so for example the containers in the app are broken down for Bank parent container notifications container and you can see that the UI tests the spec files match up pretty similarly with what we're seeing with the test and that was designed essentially because the user views of the application are going to mimic the user journeys and the user stories and that's how the UI tests are designed so we have long tests along critical paths within those views so for example in our API users I'm sorry yeah user spec there's a should allow a visitor to sign up log in and log out we can take a look at that here in our off spec so this is a very kind of long critical path test it should allow a visitor to sign up log in and log out and we see with setting up essentially the user info but we're having them sign in go through the entire process manually login going through the onboarding process that we saw in the video where they add a bank account and then it also logs them out so this is an example of one of a long user journey of a critical path that we need to make sure all of these pieces are working there are also unit tests so like I said these are within the source folder add this underscore tests and then you can run them separately on their own you can either do yarn test unit or yarn test unit CI which runs the test without watch mode so if you're running them in your CI you don't have watch what open because you're not making any changes okay so that's the approach that we took to writing the test to designing the tests and to essentially building up a test suite for the application a big part of testing additionally is also data management and that's something we wanted to demonstrate with the real worlds application because we get a lot of questions about this and it is having the right data in your testing environment is a can be a big challenge or people who write tests because it's not always linked exactly to production but we need a certain caliber of data in order to be able to run our test accurately so we're talk a little about the approach how we handle database seeding we do have an API endpoint just for test data so I wanted to talk a lot about that and then also talk about how we leverage test data within our test code so once we see that our database once we have it set up how do we actually get that data into our test codes that we can make assertions so our approach like I mentioned before we have a local JSON database managed with low DB so what does this look like in our test code so we have a back-end and this is essentially our API and then we have data and this is our database it's it's just a JSON folder it contains our users it contains transactions it's contains quite a bit of data all this data exists before the application starts we're not forcing this data to exist by running in certain transactions we're not we're essentially all this data is pre-existing but it's set up in a way that allows us to do good tests but it's all done within the database dot JSON we're just writing to JSON we don't have to spin up you know like a sequel database or a MongoDB instance or anything like that in order to be able to run the application so the database is reseeded when the app is started and in between each cypres test so you have fresh data for every single tests ike i said before it's the data is generated in advance of the application running it's based on it generated is sorry the data is generated based on business logic of the application in this c data utility script so what that looks like is in our scripts folder we have the seed data utilities what this is doing it's it's actually leveraging the business logic to create certain types of relationships between data objects that we need and to make to make good tests so for example if a user needs to have five transactions that we can you know reject one accept to dismiss three this is done in advance with without having to make those relationships ad-hoc so if you feel like taking a look at what that looks like you know creating fake users creating fake transactions this is what how we handle it in the Cypress real world app so the purpose of this is that there's no need to create that business logic within the tests so you don't have to create five transactions in order to be able to accept flow in and reject one you don't need to just create notifications in order to be able to dismiss them this is all done in advance it may not be the best approach for all data models right so we have a pretty straightforward data model it's pretty simple application and it's and we assume it was a simply designed to be able to do this but depending on your data model it may not always be possible for you to create specific data but it is essentially a best practice and if the goal is to keep the test code as clear and simple as possible which is what this app is designed to do so there is a side task so what side test does is it actually runs a command in your terminal it allows you to access that from within your test code so I mentioned earlier that there's additional scripts one of them is which is DB seed which will see your database that's the exact same script that we're using here so it can be wrong in your terminal as a command or we can leverage side tasks to run the command for us in our terminal from within our test code so we have a side task DB seed in a before each hook that runs between every tests so if we take a look at any test so we can see here there's a before each function and sideout task DB c DB seed is right here so before every single test its reseeding the database so what does that function what does that command do so in our plugins indexed es file this function is defined so we say on task DB seed it's gonna go ahead and make a post request to an end point and this end point is test data API endpoint and it's the seed and so essentially we're gonna make a post request to that endpoint and wait for it to return so what is okay so what does that endpoint do right so this is a command that makes a post request to the endpoint saying please see the database so what is this test data endpoint right so we have a endpoint specifically designed only for test data it's only purpose is to provide data for tests so if you have it's in our back with all of our other API endpoints and it's a test data routes TS is the name of the file within there we have a we're defining the end point for seed when it receives a post request it runs this seed database command so again just kind of connecting the line that what happens we have the DB seed command that runs in our terminal between every test that command is making a post request to our API endpoint our API endpoint is then running this seed database function so what does the seed database function do great question so within our database that TS file again still in our back-end we have the function declared here so C database it's essentially just using node to write to our JSON file so it is getting this it's taking the seed data and it's just writing it to database see JSON here so its DB duck set state it's writing it with the test seed and returning the data so every time that that DB seed command is running it's making a post request to our API endpoint our API endpoint is running the seed database command which then is using node to actually write the file of our database seed JSON and then once it takes that it's setting our database to that seeded data to make it match up consistently ok so last but not least so we have this database we have this database that's being seeded in between every transaction or I'm sorry in between every test that we have good data to test on so how do we use that data how do we bring that data into our test code we have we do that with a couple of custom commands for querying our JSON database so with in support slash command so if you haven't used custom commands before what it allows you to do is essentially write a function that adds a command so you can run side database or side dot whatever the command is so if you had a command for logging in you know sideout login you can use that in your test code and it will run this function so in this case we have a Sai database command that we're adding what it's doing is that it's creating essentially a psychic task command that will run a command at our terminal and that command is going to be an operation type and then database so again whenever we do side date so when you want to do side database and then we put operation find and then we have the query parameters what's gonna happen is inside so I got tasks is I'm gonna call find database pass through the parameters and run that command diving a little bit deeper so this is what those tasks actually do so if we were to run filter database it's gonna run a command that query is the database with the payload and returns the result response again we also have a find database command so going back up again just tracing the line here we run side out database we push through the operation which in this case let's say it's find and we pass through the query that's gonna run this find database command which is going to query the database and return the payload and then this is just a breakdown of what that query database function is doing which again it's leveraging our test data API endpoints in order for us to clear your data and get that back again only using our test environment and so what this looks like when we talk about actually using it in our test right here so this is an example so in our test code we have SCI database we're passing through find and we're passing through the query which is users so again if we if we were to follow that that what's gonna happen is then we're gonna run that find database and then the query payload is going to be users we're gonna make then make a call to our API endpoint with the users filled in for that parameter and that's going to return the data that we need for a test okay so we talked a lot about data and we talked about a little bit about custom commands so I just administrated how custom commands work essentially where you define them in your command set ts file by writing a function and then you can use that command anywhere in your test code there are some additional custom commands that are generated within the real world app two that I would recommend using in your own app is a side get buy sell or get buy selectors but it stands for and side get buy sell like I didn't include the entire function but essentially what this command does is it allows you to use whatever the data attribute is that you have set for your HTML so one of the best practices for Cypress is to use data attributes on your elements to query rather than necessarily trying to query from a class or an ID or some kind of arbitrary text you if you have access to your code base and you're able to set it up this way using data tests or data psy as also how it's using our documentation you can just instead of having to type that out every single time like you can see here if you had a type out but side get data test equals and then this selector that could be time consuming so in this case we're just doing a get by cell and you're passing through whatever the selector is so if you know that it's you know back button you just have to type in back button you don't have to type in the entire attribute the counterpart to this is get by cell like which essentially it's like a wild card match so we're this is helpful is for example in the application if you wanted to grab the first dismiss button for the notifications every notification has a specific ID so it's data sight darts data tests might look like you know the notification dismiss transaction ID and it has like a long ID number you don't need to type in that entire thing you just need to get you know dismiss notification that part of the selector so that's when you would use get by so like when you essentially only need to match a portion of that data attribute and not the entire thing so I would recommend using similar commands in your own applications if you're leveraging this data attribute model because it reduces anyone typing or copy and pasting if you're like me that you have to do some other custom commands so you have some login commands I wanted to point these out because essentially it's for I'm sorry it's three different ways to login so we have sign up login which takes a username and a password and then a boolean of whether it's remembering a user or not and this actually is a manual login so close to login screen it type somebody's name types in the past where did that checks the box or not and it logs them in so as you can see if you were doing this a lot typing out all of those steps would be time-consuming so instead we define it once and we use it throughout the application there's also an option to log in by API this is leverage in our API tests takes an i username and password and it actually makes a call to our API to log in or a user in the database and then I'm sorry to logging in via our server and then there's also signup log in by ex state so this is leverage in our UI tests where we don't necessarily care if the API is actually being updated we really just want to set a certain state of logged in in order to be able to test UI functionality so this is that's what this is doing its accessing the X state which is again it's a state management tool of the application and it's logging in a user within that state so within the front-end so again this is how leverage heavily in our UI so there's three different ways to login depending on what we want to test if we're testing our API we want to make sure that we can actually log in with the API if we're want to make sure that the login functionality is working and manually we want to use the side out login to run through every step and then again if we don't necessarily if we're not testing the login functionality but we need to log somebody in in order to be able to test other things then we can use log in by X date because essentially all we really need to do is just say yes this person is logged in no please let me do my other tests and again these are all defined within the support commands that TS and you can create custom commands for anything you want I mean it's it's it's JavaScript it's no it essentially and so you can leverage these it however works best for your application so if you have a certain type of functionality that is done a lot that may be time consuming to actually it's a three it step then you may think you know what I don't actually need to have the person or to have the user in this case log for each click through each step why don't I just use the our state management tool and mark them as logged in or you know if I do want them to click through to make sure everything is working and what we need to do that like maybe like 10 different times throughout our tests using a command like sideout login which will go through the steps that you don't have to type them out each time there are also a couple of transaction commands so we do have create transaction which essentially is taking in a plate load and making a call to our API to create that transaction set transaction amount range so these are Kamiya help for take a look at if you need an example of kind of creating this type of data for your tests and then we also saw some navigation function commands so next transaction feed page so this actually if you have in your transaction feed because it Scrolls I'm sorry and just kind of getting to the next section of that page and then there's also a pick date range so there's a date picker on our application which as you can as any date picker go is having to click into everything and you know pick the start date and the end date can be time-consuming and tricky to do manually so this command is leveraged throughout the test in order to where all we need is a start date and an end date and then it will go through and it'll click through and it'll it'll set the date range and pick that with the date picker in that application so I'd highly recommend using custom commands' in your own test suite just to save yourself time it's you know don't repeat yourself right it's the same kind of thing that you use for programming if you find yourself typing out the same commands over and over and over again can those be instead change to a custom command all right so talked about why the app we talked about the functionality of the app we talked about the testing of how the app works what the code base looks like we talked about the testing approach and the data management of the testing I really wanted to spend a lot of time on that section because that's what's something that we see a lot of questions around another thing we see a lot of questions around is continuous integration so if you are running your tests you know with a test runner you're you're used to that okay now I want my tests to run automatically every time I do a pull request or every time I do you know if I want to check them lightly or if I'm gonna do smoke tests however you know you whatever approach to it you take getting your test setup and your CI isn't it's also something that we see a lot of questions around so we demonstrate that with the real-world application so the real one application uses circle CI for the CI provider that configuration is in the circle CI config dot yml file it uses the cypress org so the cypress or for circle CI essentially just contains so there were dependencies that you need to run cypress in your CI it also uses a cypress docker image so we have a number of docker images available that contain all the dependencies for cypress and then we also have the option to include the cypress binary as well for that darker image it has workflows for Linux and Windows and it runs the unit API and the UI tests including mobile viewport version on Chrome Firefox and Windows so let's take a look at this configuration file so as we can see it's using a some orbs here so we have the cypress orb we have a code coverage orb and then we have windows orb and then again here we're using the docker image the node version in the Chrome 83 we have a couple of commands and this is essentially where we're defining what these commands mean and then these are workflows so we have the Linux workflow which will run some of our tests the Chrome and Firefox the nice thing about this config file it does have the comments to show what we're doing in each step so we rinsed essentially we're setting up the Linux we're installing Cypress we're running the API tests first against the bad guys back-end server I'm sorry we're running the yeah running the unit tests we're running the API tests with Chrome and Firefox and then here's where we start to run our end-to-end tests so we're running them in Chrome we're running them in Chrome with mute mobile device viewport we're running them in Firefox and then again in Firefox the mobile device viewport then we start up our windows workflow and what this is to run the tests in an electron so then again here we're running our UI tests and electron or Windows and in order to be and it's executor comes from the windows org so if you have any questions about getting it set up in CI a circle CI America set a house or built in already it's great way to get started but those configuration files with the comments can be helpful for looking for certain commands because a lot of the plug-in I'm sorry a lot of the configuration files for different CIS are similar at least the ones that use the configuration file instead of a UI base setup and so the rivalled app does also connect the cypress dashboard so that the tests that run in CI are recorded to the dashboard it is a public project so you can access the runs at any time if you wanted to use screenshots videos or output of failed runs you can sort runs by branch status committer time region tags and you can also view analytics like render Asian and test suite size so for those of you who aren't familiar with the Cypress dashboard it is an optional add-on service for the test runner that essentially it's a dashboard that allows you to log in and view test results and do have some more advanced kind of debugging and analytics features and as well as CI features like running in parallel so but if you wanted to get a look at what the breakdown of the runs for the real world app this is where you could see them so talk a little bit about responsive testing when I was going through the configuration file for circle CI I see that we do run the tests with a mobile viewport set so there's no separate UI test for mobile within our UI tests there is a is mobile check for certain tests that may that would require us to click on a different venue so the view is gonna be a little bit different when it's set to mobile viewport but we don't eat we didn't need to break out mobile tests or you know desktop tests we are able to leverage the same test suite just by setting the viewport width and viewport height to force the browser to run in that mobile view so there are two commands that you can use to run the test locally there is Cypress Open Mobile which essentially is just cypress open but it's setting the configurations of the viewport width and the viewport height or mobile and then there's Cypress run Mobile which does the same thing but it's in run mode so it won't open the test Runner and this is the same command that you can use in Persei and again this is just showing the the configuration file for a circle CI that's showing that we're running them in groups so we're going to point out here so we have the spec is the same it's just test /ui there's no separate mobile tests we have the configuration set and then we also are grouping so we have a name so it's UI chrome mobile the reason that we do this is that in the cypress dashboard the specs are broken up into these groups so we can see we have our API grouping we have our UI chrome grouping and we have here our UI chrome mobile so we can quickly see okay is it a certain browser that's failing is it the the mobile viewpoint viewport that's causing a failure by running by grouping our tests like this and bringing them out based on those different environments and based on the viewport type whether it's mobile or desktop allows us to hone in on where certain errors might be if we do experience a test failure okay code coverage so what is code coverage if you're not familiar with it essentially there's there's two approaches to testing or to validating the effectiveness of your test suite there's code coverage and then there's case coverage so case coverage is when you think of your user stories or your test cases so if I think what are the core functions that I want my user to be able to do what do I like what are the paths that they follow what are their user journeys those are your test cases and then essentially you want to make sure that your test cases cover those situations another metric that you can use is code coverage and what this measures is how much of my codebase is being touched when my tests run so when you run your test if you never ever touch like the notifications part of your codebase for example that's what code coverage would help illustrate or if you run your test and you are testing you know your signup function way way way more than you need to do maybe like substantially more than you need to maybe you say you know what I don't need them to manually log in for every command I can just set it up in the state that way you know and it'd be more efficient for the testing because we're already testing your login function several times that's what code coverage met reports help you do it helps you kind of have a bad approach for it so code coverage versus case coverage both are very important so we use the Cypress code coverage plugin again this link here takes you to the repository and it essentially helps you instrument your which like I said essentially it instruments your code in a certain way so that when you're test run it can see what part of the code base is being touched so if you wanted to generate a report you can do yarn Cypress run and then set the environment of coverage to true by default it's set to false and then you can view generated reports in the coverage folder essentially it generates that index.html file which has your code coverage report for the real world app you can also view the code coverage report looks like we have a hundred percent coverage right now and it looks like it's we have back-end and source so it is broken down into those different the front and the back end of our application so we can see right now we have a hundred percent code coverage with our tests this is going to be a really good metric for you to see to highlight any gaps that may be we need to evaluate our test cases are we you know have we written enough test cases is there work or not or are we over testing in certain areas and then just to point out that there is a code pub configuration file and what we what are essentially requirements are to pass in CI is that the coverage is between 90 and 100 or I guess at least 90 with the precision of two so if we were to run our tests and only have a code coverage of 87% then that would fail that would not allow it to proceed alright so we talked about quite a bit of things and I wanted to spend some time and just kind of review those in order before we move into questions so we talked about why the real world absolutely exists why cypress built it what the purpose of it was talked about the tech stack how to install it the file structure and how to use the app talked about the testing approach for the rogue app and how you can use that to inform your own testing approach for your own applications talked about test data management and using test data this is definitely one of the biggest topics that we talked that I hear about from our users and so I would definitely recommend taking a look at some of the different script sets around how data management is done in the real world application talk about custom commands' responsive testing and then also continuous integration and finally code coverage so there's a lot there I don't expect you to remember all of it I don't either so we have some resources that I want to share and I'm gonna make these decides are going to be are available or they're public so you can review them at any time but there's a link to the Cypress real world app on github the Cypress dashboard for the real world app the code coverage report there's also a video that I found on YouTube which I really liked it's a Cypress real world app setup and walkthrough so it shows how to install the app it goes through some of the different file structures that we talked through today if you prefer that method and then there's also the blog post that we made when we introduced the Cypress real world app as well that's actually some of the different features and functionalities alright so I believe it's time to move on to some questions and I think that we have quite a few so excited to get to dive in here so I'm gonna take a look at I think Murray if it's okay just for me to start pulling some questions from from slide oh it looks like there's omix the people can vote on them at this cool so let me take a look at some of these here what is the best practice design pattern for Cypress okay so page opt-in design like selenium or a circuit example we can reference yeah so this is actually a really really great question let me find so there is nothing preventing you from using page object model in Cypress you can absolutely do it if that would sort of works for your application if that makes sense for your for you as a the QA team or our engineering team so but there is a really great blog post let me see it I just there it is that I want to share and I can post this in the chat I was written by gleb who was our VP of engineering at Cypress it talks about stop it says stop using page objects and start using app actions so again you can use page objects if that's what works about well for you there's nothing in Cypress that's preventing you from doing that again it's JavaScript you can set it up that way however we kind of recommend talking about the actions application and again going back to like what is your user doing in your app what do they need to be able to do what's what's gonna be important for them to be able to do well and have it not great so again if you're an e-commerce website you really need to make sure that the user can go to an object or go to an item add it to their cart checkout you know complete the purchase process right because if anything on that's on that path is broken then your app is broken right you can't people can't buy things that's what it's designed to do so we talked about this approaching testing from from that those that perspective of what does your actual user journey through the application and that's when we talk about the case coverage right like are your tests covering all of those cases that your user goes through in addition to the code coverage which is a more kind of technical application of is all of our code base being touched when we run our tests so I yeah so this is essentially a good way that I recommend taking a look at this blog post so if you aren't specifically tied to page objects and you're looking for a good mental model or framework for approaching tests then this can be a really helpful and then I am since the questions I will be sending the presentation slides I can actually just do this right now and the well yeah I'll ask them to link out in this little bit because I'm not sure that's the best stuff like that that accessible link so yes I will be sending out the slides as well and then when it's okay so yeah so that's my answer as far as page opens and we get this question a lot and people love using page objects I would say that works well for you if that's a really good mental model for how you design your tests and the other caveat of that is this yours you have good test and code coverage then that's great thank in my in my opinions as long as the outcomes are what you need them to be and it gives you the confidence that you need in order to be able to have a successful application then then it's part then if you like using a certain way to do that that's fine if you're not sure if you need some guidance if you're looking for some advice I definitely recommend checking out that blog post so for API testing can we test the schema instead of the data inside the response yeah it's really a question so I just want to make sure that I'm understanding properly so when you say interrupts this schema essentially talking about the structure of the response as opposed to the data inside the response so when you think about what the response looks like for example if it is a object right if it's like a just a JavaScript object that has certain properties that you're expecting you can make assertions on that so for example if you had a I'm just kind of thinking about my head but if you had a response and yet you know it's supposed to be an object and you know that it's supposed to have you know what the user name and password in certain properties then you could make assertions on whatever the response is to assert that that structure of the object is what you expect it so yeah that would definitely be possible as well okay have you had experience using Cypress to test for actual queries and mutations yes so this is a really really really good question there are it is possible there are some workarounds that are needed there's a github issue that has some workarounds let me see it if I can find if I can't find it in like 30 seconds or 45 seconds and I'll send it out afterwards but yeah so that it is possible what what essentially what happens is that you have to listen to everything and then see what matches up if that makes sense because Cypress is intercepting Network calls but the way that graph qo works is that because it there's not specific endpoints for data and said you're passing through whatever your query is or not sure the exact terminology but then and then it gives you the response based on what what data you're asking for so there's not the way that like a REST API works where you're saying if I go to post endpoint this then I'm supposed to get a response so I go to this endpoint this it's supposed to get a response so you do have to essentially just catch everything that's coming back and then see what matches up with your data so there's a workaround for it I couldn't find it in 30 seconds while talking so I think I'm look that up though I can definitely get that - Maurice that she can send that link out and I'll post it on it as well and that would be a really great you know blog posters with documentation as well alright so taking a look at some other questions here looks like there's some in the chat as well so I'm gonna try and check is there so if you could share your questions from this slide oh that's probably the easiest way for me to see it because if I made you have quite a bit of questions but next one is when you run a group of tests in the CI it runs too quick so you sequentially or in parallel great question so you can do either so if you're running your tests and CI it depends on how you have it configured you can run in parallel if you're using the cypress dashboard so we leveraged smart parallelization that looks at all the history of your test runs figures out the most efficient way to split that up across your machines and then it runs the tests in parallel there's something so that's essentially something that happens within the cypress dashboard but when you setup your CI runs you can you can do that yourself it won't have the smart travel as a stone that Cypress does and it's gonna take a lot of additional configuration but it's all dependent on how you set up your tests to run in CI Cypress doesn't prevent you from doing anything in particular and we have a lot of different examples so we have for example we have jenkins we have oh my gosh so many i can i can just actually we have a section we have a whole continuous integration guide in our Doc's which i use constantly to to look at example configuration files so i'm gonna just kind of pop this in the chat here but this there's an example section that has yes we have a AWS amplify a player as your bitbucket bill kite circle CI con course get lab jenkins Travis CI and these all have example configuration files for running in basic and then also running in parallel yeah so you can all you can make parallel tests it does require additional configuration absolutely X for the other thing there like about Cypress is that like aside from some known like some known trade-offs if you were to do something we can probably figure as long as it runs in a browser so okay taking the next question I also want to make sure that we're doing okay on time to summary feel free to to interrupt me if I'm going too long so with apps developed in react and request our window to fetch rather than xhr any yes okay any working examples of requests call weights which are fetched in Cyprus tests so there's a couple workarounds so currently Cyprus does not support fetch that's something that's on our roadmap is full network stuffing it's actually if we actively work done right now but the workaround in the meantime is there's a couple different ways that you can approach it we have we have it in our documentation let me see actually if I can find that exact link so there is an experimental pitched that polyfill all that stuff to say and I can send the blog post for that essentially this is this is a precursor to full network stubbing which is on the roadmap but it allows you to essentially polyfill those sex requests you can also disable such entirely on the window which will force everything to turn into xhr and you can intercept it that way but there's obviously some some cases where that would work and so that's where the experimental fetch polyfill comes in and this can be enabled right away but it is experimental so you have to turn it on so that's something that you're interested in you can definitely explore that okay perfect all right so okay this is yeah so next question here from your experience have you seen more software engineer developers using Cypress or QA test engineers it's actually so I when I first started at Cypress I thought that it would be more developers but it's actually a lot we actually have quite a bit of QA I would say it's probably almost again this is anecdotal I don't have like hard numbers but just from the people that I interact with I would say it's actually probably almost a 50/50 split between developers and QA I I think there's a couple different reasons for that you know cypresses you have all that extra functionality because you can access node and you can access the show from within your test code so I think developers like that you can do extra things with it and then I think also for the QA aspect of it is before so just yeah you know Cyprus is pretty easy to get up and running as far could we try to make the commands as syntactic as possible as English like as possible and so I actually have seen a pretty even split between uh software engineers in QA is database a reserved name in Cyprus I don't think so that that's a good question um it's not an override command is if you're referring to the Cyprus commands so if you wanted to actually say for you can actually overwrite any existing command as well leveraging custom commands so say for sie doch click for example and this is actually what Cyprus movie does Cyprus movie overrides certain Cyprus commands and slows them down so you can change the functionality of Clips to slow it down you can change the functionality of some of any kind of commands if you wanted it to do something specific whenever you do you do that are you creating real data the database instead of mocking data yeah so we are actually seeding the JSON database with real well with real fake data every time so when and then the same thing happens when we're running transactions so the reason that we're Ystad the database between every test is because when we have tests that update the database by you know creating transactions updating profiles different things that is creating real data in the database so it's testing that full functionality of our API in our application so we can do both right you can mock responses if you don't need to test that functionality but this is also creating real data in the database to make sure that's working as well so you can design your test feed around what you need to test and making sure that you're writing tests for those things and not duplicating it when you don't need to yes the more developers yeah so the develop that's it that's a good thanks back for kind of pointing out that context so I do see wheat so I think about probably every one people have may have heard the term shift left right where we see more developers writing tests that rather than having the test code I'm sorry rather than having the software code written in isolated isolation throwing it over the wall so to speak to QA and then the test would being run and written in one in isolation we are seeing more collaboration between the two different teams Co sometimes I'll be on calls to people it's like we have the engineers and the QA because they work together I've seen different situations where you know developers will will write tests for new features and then QA is responsible for writing you know the tests for existing feature is the smoke test the kind of edge cases I've seen that kind of model before so I think we definitely have seen I think I think that maybe Cyprus has a higher percentage of developers running tests maybe than other tools I again that's kind of anecdotal that's not hard data don't go home weight to that but I would say that I do see that a little bit more adoption among developers may be a with Cyprus what is the best way to get data test attribute to add an application good question so we talked about that right so essentially if you have access to your codebase and you know which elements that you need to test you can go into that HTML element let's say it is a lake and you just add you know an attribute so you can do data - psy equals log in link whatever whatever it is that's named now if you don't have access to the code base and it's tougher so that's why I say if you're able to do this it's a great best practice or if you're able to if you don't have access the code base and you're able to get developers to add those references in there for you it essentially just allows you to be very prescriptive with what elements that you're querying for and you're getting back so you don't have to worry if you have a certain class for example when it returns like 10 items then you don't necessarily need to say ok I want the first one you can just go directly to whatever that first one is or you can go directly to the exact element of what's happening so you'd always know that you're getting the right element that you want ok um great questions I'm trying to just check the chat real quick and see if there is any additional okay yeah so looks like you have a bunch of new questions if anyone who wants to vote on questions to see which ones did ok is it possible um Cecilia sorry just so quickly in there abuse so because we only have five more minutes at the end we could just always callate the questions because I'm curious about your time as well so maybe what we could do is we could just answer a couple more and then we can send the list of the other unanswered questions and then just share it on like a Google Doc where somewhere then we can share it on the meetup group perfect and that will give me a chance to get some of those resources here thank you yeah all right great then yeah so doing five minutes left I did want to just kind of thank everyone for your time and again if you do have any questions please submit them you know summary look at that look at the question lists together so I can respond but again I'm Monica hub as Cyprus Cecilia for anything in Cyprus related well so one good hub as Cecilia crates for all my personal projects I do have a website to sell you crates calm and then you can also reach me on twitter i'm i'd love talking to people about Cyprus and about disgustin in general so and I love hearing people's experiences with it so if you have any feedback you know definitely feel free to reach out to me and thank you so much for taking the time to listen and to ask great questions you'll have some really great questions wonderful thank you so much as Leah for doing this wonderful session in fact so to be very honest with you this is something that I really wanted to explore so that was the catalyst in fact I learn a lot about this particular application as well so once again thank you so much for answering all the questions patiently and thanks everyone for joining and please do support us and of course we have next a few more sessions that are planned in the upcoming months as well so please do join us and have fun thank you so much cheers guys take care bye thanks everyone [Music]

Channel: Cypress UK Community

Views: 1,417

Keywords:

Id: jZly1Cpun-Q

Length: 63min 29sec (3809 seconds)

Published: Thu Jul 16 2020