Cypress Best Pratices for Test Automation

Presented By:
Hitesh Mahi
Software Consultant - Test Automation
Cypress Best Practices for
Test Automation

Lack of etiquette and manners is a huge turn oﬀ.
KnolX Etiquettes
Punctuality
Join the session 5 minutes prior to
the session start time. We start on
time and conclude on time!
Feedback
Make sure to submit a constructive
feedback for all sessions as it is
very helpful for the presenter.
Silent Mode
Keep your mobile devices in silent
mode, feel free to move out of
session in case you need to attend
an urgent call.
Avoid Disturbance
Avoid unwanted chit chat during
the session.

Our Agenda
01 Introduction to Cypress
02 Why Cypress ?
03 Cypress Best Practices for Test
Automation
04 Explanation with Examples
05 Demo

Introduction to Cypress
● What is Cypress? Cypress is a next generation
fortend Automation testing tool built for the
modern web applications.
● “Fast,easy and reliable testing for any
application that runs in a browser"
● It is a JavaScript-based end-to-end testing
framework built on Mocha – a feature-rich
JavaScript test framework running on and in
the browser, making asynchronous testing
simple and convenient

Why Cypress?
● The people behind cypress must have strong reasons to put this
statement on their official documentation - “Fast,easy and reliable
testing for anything that runs in a browser”.
● In a nutshell, why cypress? They are claiming that cypress address
the key main points that dev or qa may face when testing modern
applications.
● Like synchronization issues, flaky or inconsistent output from test
cases.
● All these points makes cypress more desirable as an automation
tool.

Cypress Best Feature
● One of the most important best practices you can
adopt when creating your E2E Tests is writing
selectors completely independent of your CSS
or JavaScript.
● In order to prevent your test suite from being
broken by a simple CSS or JavaScript update,
you should construct selectors that may be
explicitly targeted for testing.

Best Practices in Cypress
● Selecting the Elements
● Visiting External Sites
● Having Tests rely on the State of Previous tests
● Using Hooks
● Unnecessary Waiting
● Setting a Global BaseUrl
● Using Comments

Selecting the Elements
● Every test you write will include selectors for elements. To save yourself a lot of headaches, you
should write selectors that are resilient to changes.
● Your application may use dynamic classes or ID's that change
● Your selectors break from development changes to CSS styles or JS behavior
● Do not target elements based on CSS attributes such as: id, class, tag
● Do not target elements that may change their textContent
● Add data-* attributes to make it easier to target elements

Example Code
● In the Below snippet we have used the “data-cy” attribute to overcome such issues
● adding the data-cy attribute to the element gives us a targeted selector that's only used
for testing.

Visiting External Sites
● One of the first things many of our users attempt to do is involve 3rd party servers or services in
their tests.
● You may want to access 3rd party services in several scenarios:-
● Testing log in when your app uses another provider via OAuth.
● Verifying your server updates a 3rd party server.
● Checking your email to see if your server sent a "forgot password" email.

Challenges Faced with External Sites
● The site may have changed or updated its content.
● They may be having issues outside of your control.
● They may detect that you are testing via a script and block
you.
● They site might have policies against automated login, leading
to banning of accounts.
● They might detect you are a bot, and provide mechanisms
such as two-factor authentication, captchas, and other means
to prevent automation.

Possible Solutions
● Use another platform that you control to log in with username and
password via cy.origin().
● This likely guarantees that you will not run into the problems listed
above, while still being able to automate your login flow. You can
reduce the amount of authentication requests by utilizing
cy.session().

Having Tests rely on the State of Previous tests
● You only need to do one thing to know whether you've coupled your tests incorrectly, or
if one test is relying on the state of a previous one.
● The important coding standard that we have to follow here is that the code written in
one it() block should not be dependent on another.
● The reason for this way of coding is that when we run a spec file with multiple it()
blocks(Example: 15 test cases), if one it() block fails the remaining it() blocks won’t fail
since there is no dependency between them.
● On the other hand if one it() block is dependent on another block it will make remaining
test cases fail

Example Snippet
● In the Below Example we have combined the block into one single test

Using Hooks
● Consider a scenario where we have a spec file and we have 10 test cases
in that spec file and for each and every test case we need to write 2-3
lines of code that is common to all test cases at the start of the test case.
● In this scenario it is not a good practice to add the same repetitive lines
of code at the start of each and every it() block.
● The solution is that we need to write the code in beforeEach() hook.
● Same way we can use afterEach() hook to write common code to be
executed after each and every test case got executed.
● Also we can use before() hook to write common code to be executed
before all test cases got executed in a spec file.
● We can use after() hook to write common code to be executed after all
test cases

Unnecessary waiting
● In Cypress, you almost never need to use cy.wait() for
arbitrary amount of time. If you are finding yourself doing
this, there is likely a much simpler way.
● A better solution is to write dynamic wait code using
cy.intercept().
● The main advantage of writing dynamic code is that it saves
the waiting time and executes the script quickly.
● The main advantage of writing dynamic code is that it saves
the waiting time and executes the script quickly.

● In most of the applications the base url of the application is the
login page.
● In all the spec files we need to use the login url as the base url for
login and perform other test activities.
● Some developers hard code the base url using cy.visit() in the
before() block of each spec file
● This is a wrong practice because when we run the spec file in
cypress runner, it will initially load the localhost url and then
reload the url we gave in the cy.visit().
● To overcome this issue we can write the base url in the
cypress.json file
Setting a Global BaseUrl

● Here in the below snippet we hard coded the base url using cy.visit() in the before()
block of each spec file which is not correct
● To overcome this issue we can write the base url in the cypress.json file as shown below.
Example Code

Using Comments
● It is a good practice to put comments before
each block of code we write inside it() block.
● so that when others view the code we wrote, it
will be easy for them to understand functionality
that is being automated in the script.

Thank You !
Get in touch with us:
Lorem Studio, Lord Building
D4456, LA, USA

Cypress Best Pratices for Test Automation

More Related Content

What's hot

Similar to Cypress Best Pratices for Test Automation

More from Knoldus Inc.

Recently uploaded

Cypress Best Pratices for Test Automation