Why Cypress is need of an hour!
How do you test your front-end? Automation or Exploratory Testing?
If you leverage e2e acceptance scenarios within Sprint, then what tools you use to finish & ship workable features to product owners.
Are you happy with your current stack? Don't worry, let's explore Cypress as your main e2e testing tool in this Dev series.
Here I am presenting very first episode of this series.
let's see some point why we need Cypress in this new world of front-end technologies.
As Cypress says :"The web has evolved. Finally, testing has too."
Cypress is e2e test tool with few limitations, off course, but at the same time Cypress is making e2e testing very easy to a great extent with it's killing features.
Today in this episode, I’d like to talk about how you could leverage Cypress as a testing tool in this modern front end era.
There are two ways to test now a days I can say....
It's other way or Cypress way to test things!!!!
Why UI testing is hard sometimes? read below:
To Test any front-end application via automation test introduce few challenges that the exploratory(manual) tests doesn't have,
you need to simulate a real browser the similar kind of user interactions the end user would do for the product & assert the output for this action.
All these test steps are what make UI testing even hard for us.
- JavaScript is asynchronous: Web UI reacts asynchronously, browser reacts asynchronously, tool we used to communicate with the browser is asynchronous
- Hard to interact with few elements in DOM: In any web application, appearance of some element is tough. Some of them are easy to be discovered but some are not.
- We automate e2e app design flows: Pausing a running test is hard and we need to relaunch the same tests a lot of times to check it's true worth in test framework.
so at this point it looks like automation testing of a front-end application is hard. but hold on.....
Let's talk about other way first...how we are testing since long time....
to build a good automation framework we need below common tools.
- Test runner for e.g. Junit or testNg
- Browser automation APIs for e.g. Selenium
- Reporting library for e.g extent
- Need to implement logging separately for e.g log4js
- Need to implement lots of utils classes for e.g. wait,JavaScript executor, action & so on....
- Need to implement data driven leveraging excel separately.
- List goes on
But don't worry, Now let's look at the Cypress way to give us smooth experience start from installation to write/run our first test.
calm yourself down, my purpose is not to create a panic here about stuff which we are already doing good with mix of tools/libraries/APIs but struggling sometimes unknowingly, my main aim here is just to make you aware that you do not need generic tools mixed together.
we have a tool which is made on purpose i.e Cypress the UI testing tool.
How does Cypress solve all the above problems?
Built in test runner in Cypress
Install cypress & launch the same with below commands. you start Cypress via two methods,
Cypress open or Cypress run
npm install cypress --g
Add below script in your package.json file.
{
"scripts": {
"cypress:open": "cypress open"
}
}
Now launch Cypress with below:
npm run cypress:open
you will see below screen open with list of all specs which are present in integration folder of cypress.
This is how cypress test runner look like on launch of the test:
- You can see all specs before actual run in first image. you can run entire suites of test or just double click on single spec to run. on top right corner you can see list of browsers.
- you can see URL preview
- you can see default view-port sizing
- you can see command log UI (on the left) which runs with your application (on the right) i.e in App preview.
let's see some of command log UI features?
We have see in test runner for what Cypress is doing for every line of code written in spec file.
Whenever we trigger Cypress to interact with our app through its commands like (cy.visit, cy.type, etc...), Cypress adds a log to the Test Runner. This automatic logging is quite helpful both while writing/debugging our test. This improves our productivity to a great extent believe me.
Time travel feature(yes you read it correct)
We can hover the various logged steps and see how the app looks at a particular step & we can pin a step and inspect the DOM, check how the app looks before/after the step, etc. even we see before/after screenshot in app preview.
This is excellent feature, both at the first approach (debugging a test when you do not know much about tool could be a nightmare) and in the day-by-day testing work.
Logs in left pane: clicking on command shows a more detailed log into the browser Dev-tools.
Assertion verification
clicking on an assertion shows both the expected value and the result in the browser DevTools. no not need to relaunch the test.
… and much more, take a look at actual docs of Cypress testrunner
Cypress commands
All cypress commands are asynchronous by default. you will not find await that's awesome right, you need not to worry about await stuff, Cypress handle this in a unique way internally.
it('loads', () => {
cy.visit('localhost:5500')
cy.get('.new-todo').get('footer')
cy.contains('h1', 'todos')
cy.contains('h1', /^todos$/)
cy.contains('[data-cy=app-title]', 'todos')
})
Cypress “waits” for you, which means Cypress retries (by default for 4 seconds set in configuration) for element in DOM until it can interact with the element So you can avoid asynchronicity at all.
Most Important in my views: DOM-related commands report DOM-related errors the way you need. Take a look at the following example:
cy...() failed cy-method-failed-element-is-detached
Cypress reports clearly the problem from a user/DOM perspective.
Cypress display errors logs very descriptively so that we can leverage them to fix the test easy & fast.
Cypress improved our overall productivity
Cypress helps me to complete automation test within sprint only quite effectively compare to earlier tools.Cypress force us to follow DRY principles.
Cypress Automatic relaunch spec as soon as you write & save the change in VScode.
Cypress open a dedicated Chrome user, we can install your DevTools of choice and use them inside the browser controlled by Cypress
Cypress gives us full access to the window object.
Cypress improved our Debugging skills of test
debugging a test for QA folks was a nightmare due to lack of dedicated features in earlier tools.
Cypress have Play/pause functionality
we can leverage above using UI as well as programmatically.
we can pause the test and resume it, one can see step-by-step navigation, the same way when Devs used to place a break-point in their code.
Provides screenshots and videos
On test failure, Cypress saves a screenshot of the last step of the test. Cypress records a video of the whole test, including the Test Runner UI.
This is the most loved featured in my views as this gives us more power to debug those test which usually work in local setup but failed in CI/CD like Jenkins or Team-city.
Let's warp the episode 1.0 here. Thanks for reading. Stay Tune for next episodes.
Please leave your valuable comments so that we can learn from each other.
I know I know, I am almost biased on Cypress as a perfect tool in this episode.
Will discuss some cons in episode 2.0
Join us on WETESTERR Community
Subscribe to our YouTube for Tech podcast
If you like this article chances are you will like my other article as well 👇
🚀https://dev.to/tyaga001/my-tech-journey-in-software-testing-5fol
🚀https://dev.to/tyaga001/chropath-is-no-more-a-xpath-finder-tool-it-has-evolved-a-lot-now-13fd
🚀https://dev.to/tyaga001/generate-stub-test-data-using-jfairy-in-selenium-2c2m
Top comments (2)
Good read Ankur
I am using Cypress currently and I really like the level of debugging we can do
Thanks a lot Sai.