It's been 3+ years working with Cypress.io and now, I completely think(so but catching up with Cypress updates is endless) understand the hurdles that need to be crossed and pave a path for Selenium QA Engineers to make them understand the actual differences vis a vis Cypress & Selenium world. now, Why JS? The reason wise, Cypress only understand JS. It's going to be multi-part series around what I've learnt while taking the leap into the Cypress world.
“The journey matters as much as the goal.”- Kalpana Chawla
Her above quote resonates the idea of working towards a goal and the experiences we have along the way are just as valuable as the goal itself. The journey can be full of challenges, failures and learning experiences which can shape us, make us stronger and better equipped to face the future.
Cypress.io has such a nice documentation that I can't think of referring other tutorials/blogs to you. Here, is the starter kit for you:
Now, I can safely assume that you've set up everything for writing the Cypress+ JS code in Mocha style using IDE of your choice (mine is VS Code)
In my opinion, understanding the following concepts is essential for effectively utilizing Cypress. So, Ready to bite the bullet?
- Cypress Commands Are Asynchronous
- Cypress Commands Run Serially
- Cypress Command Chaining
- Subject Management in Cypress
- Context Switching between Cypress & jQuery [.then() & .wrap()]
Let me take all pointers one-by-one and break them down, while adding code snippets to make things more clearer to you.
- Cypress Commands Are Asynchronous
It simply means that as soon as you run the Cypress tests, commands don't get executed right away but get queued to be executed to a later time. Cypress does not wait for one command or action to be completed before moving on to the next one. While commands are executed, their subjects are yielded from one command to the next, which allows for faster test execution and more efficient use of system resources. This also allows Cypress to automatically handle waiting for elements to load or for certain conditions to be met before moving on to the next step in the test, which simplifies the test writing process.
- Cypress Commands Run Serially
It means that Cypress Commands execute one at a time in the order that they are called. It has been possible by the hard work put in by Cypress Team to make use of a built-in command queue to ensure that commands are executed in the correct order. The serial execution of Cypress commands ensures that each command has a chance to complete before the next one begins. This makes it easier to reason about the state of the application under test and to understand the results of the test.
- Cypress Command Chaining
This allows multiple commands to be chained together in a single line of code. Commands are designed to be chainable, meaning that they return the same subject that they were called on, allowing you to chain multiple commands together & allows for more concise and readable tests, as well as the ability to perform multiple actions on a single element. For example, instead of writing separate lines of code to visit a website, click a button, and then check the text of an element, all of these actions can be chained together in a single line of code.
Catch you in the next article coming next week.
Part-II has arrived now and here is the link to Part-II of this series. Feel free to comment on this.
Please refer to my online portfolios:-
LinkedIn
GitHub
StackOverflow
Top comments (0)