Tests Structure | Bondar Academy
Course: Cypress UI Testing with JavaScript
Module: Cypress Hands-On Overview
Instructor: Artem Bondar
Lesson Summary
In this lesson, we explore the Cypress test structure and how to effectively organize tests within spec files. Here are the key points covered: Creating a Spec File Create a new spec file in the root of the E2E folder, e.g., firsttest.cy.js . Add a reference to the Cypress library by copying the first line from an existing file, such as todo.cy.js . This enables IntelliSense in Visual Studio Code, allowing you to see available cy commands. Writing Tests Each test starts with the it method, which takes two arguments: Test name (e.g., hello world one ) A callback function using fat arrow syntax to define the test logic. Run tests using npx cypress open to see them recognized in the Cypress runner. Organizing Tests Group tests using the describe method, which allows for nested test suites. Example structure: describe('Test Suite One', () => { it('Test One', () => {}); it('Test Two', () => {}); }); Using Hooks Utilize test hooks like beforeEach and afterEach to perform actions before or after tests. Example of beforeEach to navigate to a homepage: beforeEach(() => { cy.visit('/'); }); Avoid using before or after hooks as they may create dependencies between tests. By following these guidelines, you can effectively organize your tests within Cypress spec files. In the next lesson, we will build on this foundation.
Video Transcript
All right, guys, in this lesson, we will talk about Cypress test structure and how to organize your tests within the spec files. Let's jump into it. So for that, let's create a new spec file in the root of E2E folder. Right-click, New File, and I will call my file, let's say, firsttest.cy.js. So you see, it's a blank new file, and let's organize it. So first of all, you need to add a reference of the Cypress library into this file. So go to one of the examples that we have, for example, todo.cy.js, and copy the very first line, Ctrl-C, and paste it over here. So why this reference import is important? This reference import enables IntelliSense inside of the Visual Studio code. So when you type cy command to call different Cypress method, you will see the dropdown with the available lists of method. If you will not use this reference, most likely, VS Code will not be able automatically to pick this up. You simply will not know which methods are available and which are not. So you need to put this reference into every spec file. Then, every test in Cypress start with the keyword it, and this is a method. So it and parentheses, this is a method. This method has two arguments. Argument number one is the test name, for example, hello world one. This is the test name, and then you put comma. And the second argument is the JavaScript callback function with a fat arrow syntax. So if you check the JavaScript fundamentals module, you know that this is anonymous function with a fat arrow. And inside of this function, you will write your tests, and that's it. So here you put the code, and then you put the test number one, then the test number two, test number three, and so on. If I will open Cypress runner, new terminal, npx cypress open, scrolling a little bit down. And this is the first test, the cy.js. And I run it, and here we go, two tests were executed. Both of them are empty because we don't have anything in it right now, but you see runner recognize those tests. What else, moving on? So you can also organize your tests in the groups or test suites using a keyword describe or method describe. So I type describe, and syntax will be the same. For example, test suite one, then I put comma, and also my callback function like this, and curly braces. And then inside of the test suite, I can put my tests. And for example, quick reformat, hello world three, hello world, let's say, four, and going back to the Cypress. Now you see that a new kind of a dropdown created within the runner. We have hello world one, two, and then three and four. And you can create the nested structures, pretty much they are unlimited. So if I put the current describe with two tests into the existing describe, this is test suite two, this describe has another describe. And look, if I go in back over here, so we have test suite one, which have two tests, and another nested test suite with another two tests. And this structure is kind of unlimited. Or you can take, for example, this second test suite. I make command X, remove it from here, and add it at the end like this. And by the way, for the quick formatting on the mark, I use Option-Shift-F. And the file is automatically nicely formatted. So and going back to the runner, and you see we have test suite one, test suite two with group test. So you can use this grouping however you want, whatever makes sense for your environment to organize test within a single spec files. Now let's talk about hooks real quick. So Cypress and many other frameworks has a concept of the test hooks. When you can repeat a certain operation before the test or after the test, or before each test or after each test. For example, let's say that we have this describe test suite, this test suite one. And for this test suite, for each of these tests, we want to navigate to the home page. So I am calling the before each hook. It has exactly the same syntax as the test file or the describe. So for example, open test application, this is what my hook is doing. Then I put the callback function right here. Here, let's say I want to open my app and I call the coi.visit. This is the method to open a web page and then provide the URL what I want to open. Since we have defined base URL in the configuration file right here, all I have to provide is just a forward slash. And Cypress will know that, hey, I want to open our test application that way. Now let's go back to the runner. Runner already executed this, and look, for the test Hello World 3 and Hello World 4, for every test, the test application was opened right here and right here. But it was not executed for these two tests or for these two tests, okay? If I will change my before each hook from here to the very top of the file, to the higher level of the spec files and go back. Now, the test application was open for every single test, including the test suite. See, the visit was executed all six times. The same is related to after each hook. For example, after the test, you want to run certain scenario, maybe delete the data in the database or something like this. You would use after each hook and would use the same exact syntax, providing the code inside of the callback function. What do you want to do after each test? If you want to run something just once, there is also a hook called before or after, but I would not recommend using this hook in Cypress, actually, because it creates kind of a dependency that this step will be executed before the first test, but the second test may not know the context that was executed over here. So that's why I don't recommend to use it. So if you use hook, use before each or after each hooks. So that's pretty much it, how you organize the test. Now, let me clean this thing a little bit up, and I will prepare this environment for the future lessons. So I will remove all this. I will keep only the first test like this with the before each. So is it working? It's working again. And also, I probably will remove these two examples, getting started and advanced examples. I don't need this because it creates the noise in the Cypress runner, moving to trash, and my E2E folder has only one spec file, firsttest.cy.js. So let's double check what we have in the runner. Yeah, this is what we have, only single file displayed in the Cypress runner. So that's it, guys. This is how simple is it to organize tests within the spec files, and I'll see you in the next lesson.