Why Cypress? and why not?
Tags: testing, e2e, cypress, javascript
Published: 2020-10-04 08:40:41

I know it's long overdue but like a true politician just before any election, as I have promised, here are the reasons why I wanted to refactor our "🐢-like"-slow Selenium framework into Cypress.  
In my previous [article](https://dev.to/poponuts/selenium-to-katalon-to-cypress-io-1lid), I initially intended to create a comparison table but I had a moral realisation to focus on Cypress itself as Katalon & Selenium have their own advantages and what may work for me may not work for others. There is **no** silver bullet in end-to-end testing, although, in my opinion, Cypress comes close to closing out the gaps.  
###**Why not Cypress?**
_A.K.A. When **not** to use Cypress (I made it a checklist and if you tick ALL then I just saved you from wasting a few minutes of your life going through my whole write-up below)_
❌ No native tagging (although, [this](https://www.npmjs.com/package/cypress-select-tests) may work if you have older versions of Cypress or [this](https://www.mariedrake.com/post/using-tags-to-filter-your-cypress-tests))
❌ Parallelisation (is that even a word?) is a pain if you are poor (unless you tricked your company to pay for [Cypress dashboard](https://dashboard.cypress.io/))
❌ Only in two languages so far (Javascript & Typescript)
❌ Does not support multiple browser tabs
🤑 Your managers don’t like open-source and get perks from vendors who can sell their licensed automation products for six digits 

For reference, here's a detailed [list](https://docs.cypress.io/guides/references/trade-offs.html#Permanent-trade-offs-1) of trade-offs from Cypress team to make your excitement go away (Remember, [fail fast](https://en.wikipedia.org/wiki/Fail-fast) though? It's easier to learn early it's not going to work than find out later when sweat investment has been spent).

###**Why Cypress?**
_I took the privilege of grouping them so it fits easily on your powerpoint presentation (or google slides if you are a fancy cloud-based startup)._
✔️ Speed is paramount (Heaps faster than anything on Selenium Webdriver - nuff said)
✔️ Debugging is a breeze (time travel with screenshots and video recordings)
✔️ Flaky environments will be a thing of the past (Aysnc and re-tries for the win!)
✔️ Easy maintenance (smart waits, easier capturing of elements, lines of code refer to actual tests and not on firefighting the waits)
✔️ Extensive documentation (The gold standard of documentation I have seen on the net!)

###**Bonus**
_... as in make this an optional slide on your pitch deck if there are still rolling eyes and death stares from the audience_
* [Unit](https://github.com/bahmutov/cypress-react-unit-test) and [Component](https://docs.cypress.io/plugins/index.html#component-testing) testing 
* [Cross-browser tests](https://docs.cypress.io/guides/guides/cross-browser-testing.html) (Chrome, Edge, Firefox, Electron - who tests on Safari, anyway?)
* Javascript (quick learning curve for front-end engineers!)
* Great support from the Cypress team (and growing community!) - _although the framework is gaining massive following - the growth means less time to respond to queries - Well, I have suggested the team to use a community forum with moderators as compared to the chatroom-like [Gitter](https://gitter.im/cypress-io/cypress) which they use now_ 🤷‍♂️  

***

There you go! Just like what engineers do in stackoverflow, feel free to copy-pasta the above to justify and beg your manager and team to adopt this framework. Thank me later.