First impressions of Cypress; one word: amazing.

Found testing automation tool called Cypress for use with end-to-end (acceptance/user) testing. Tagged as `Fast, easy and reliable testing for anything that runs in a browser`. Having used, abused, cursed at, threatened, and broken a number of testing tools I thought this would be another interesting trip down frustration lane…boy was I surprised,

What makes it different?

From the https://www.cypress.io/ site:

1. Does not use Selenium.
2. Focuses on End-to-End (Acceptance/User) testing; not an automation framework, not for back end services, not a browser emulator.
3. Front end framework agnostic.
4. Tests are written in JS, no other syntax is supported; allows for the tests to be executed in the browser, not via a separate piece of automation.
5. It is all in one, no dependent programs or binaries post install.
6. Focuses on making TDD easier; aimed at Devs and QA engineers.
7. Built for speed.

Most testing tools operate by running outside of the browser and executing remote commands across the network… Cypress is executed in the same run loop as your application.

…but my favorite point (if it holds up) is this one: Cypress is not flaky.

So here we go…

Getting Started:

Because I try to do my development as isolated services I avoid npm outside of front end code development; thus I used the direct download option. It came as a zip file so I unzipped it into a project directory ~/…/Projects/tools/Cypress . Clocking in at 28k (thousand) file objects totalling 441 Megs uncompressed it is not the smallest tool on the block.

Bonus points from me, the documentation has a CI/CD integration guide as well as a link to a docker hub container image with all the system dependencies pre-installed.

So I execute the Cypress binary from the terminal, the directions only had instructions on how to start it via NPM so I guessed. After a few moments I am greeted with the main UI. Success!

The documentation goes on about environmental variable setting and firewall navigating, download specific version and platform options.

On step two we write our first test. The documentation starts out with a video first. the TL;Dr is to create a directory ./cypress to put the tests in, use JS w/ Jest syntax, and leverage the built in functions to control the emulated users actions.

The boilerplate directory has some sub-directory with example files to get you started. Double clicking on the example test file in the Cypress UI launches a browser and executes the test. Props to the Cypress team for having such an exampled boilerplate.

Running and looking through the test I came across the DOM traversal test.

it('.nextAll() - get all next sibling DOM elements', () => {
  // https://on.cypress.io/nextall
  cy.get('.traversal-next-all')
  .contains('oranges')
  .nextAll()
  .should('have.length', 3)
})

Now, I am a PHP / Back end engineer by trade; I can read that, it makes sense to me. Watching the text executed live, and the speed. I almost fell out of my chair. Once the browser client is open this thing (Cypress) is fast, really fast.

At this point much of the syntax is looking familiar. Turns out Cypress builds on the Mocha and Chai JS testing libraries. I would not be surprised to see Jest in here at some point.

…adding a little logic here we get a successful execution.

At this point I started playing around with different content to find and selectors to use. A couple things I noticed I REALLY liked.

• Saving a *_spec file re-runs the test suite in the browser the Cypress App opened. 1 extra tab/client open to run tests.
• The Cypress UI has a direct link to the documentation
• The frames in the UI in the browser (Application Under Test – AUT) are configurable via the projects .cypress file.
• The tests run amazingly fast.
• You have the ability to visit every step of the testing process and view the application at that moment, not just the final state. The browser console provides an interface into what Cypress is doing each and every step.

Conclusion

Over the course of the 3 hours I spent on this initial impression blog with Cypress I was hard pressed to find an big show stoppers. It’s easier to install, write, run, and debug front end testing suites. The documentation and demo projects work, and it does not depend on fragile multi-binary / interface APIs.

The downsides, if any, would be that Cypress intercepts network traffic; so it requires fixtures and stubs. This can be worked around but is not central to the Cypress design principle. The other downside would be that Cypress is not well know / wide spread. Thought in this persons opinion, it should be.

TL;DR

I wish I had this 3 years ago. So many headaches, late nights, and hours of frustration would have been saved. I will defiantly be using this next time I have to implement end-to-end testing.