For some time now, I’ve been leading the QA efforts at Stoplight - a USA-based startup that we are the engineering partner. To give you some context, Stoplight builds products in the API domain. They are the creators of the API design Studio, an enterprise API platform for managing APIs at scale and generous contributors to the OpenSource (see Prism or Spectral for example).

Awakening of Cypress

Until about a month ago, our team was happily using Codecept. As it often happens in startups, things change, and we now joyfully code our tests with Cypress :).

Yes - we ditched all tests we wrote, re-thought our approach, and wrote them from the ground up!

Was it the right choice? What did we learn on that journey? Well, keep on reading to find out!

The Grand Redesign & The Window Of Opportunity

At the time, we were deciding whether to switch the frameworks or not Stoplight was at the end of a significant product redesign. That allowed us to redo most of our automation suite.

As you can imagine switching to a new framework was not a light decision. Our crew was pretty knowledgeable about Codecept and, despite it having many bumps, we weren’t sure if Cypress would help with anything.

The promise was bold, though! Because of how the Cypress is written we were supposed to get:

• 0 flaky tests,
• faster execution,
• better onboarding,
• and more versatile debugging!

In other words, we were expecting to be able to write lightning-fast and stable tests in less time!

Now, after about a month of working with Cypress, I can share my initial impressions, lessons learned, and top tips that should help you onboard to Cypress and make fewer mistakes than we did!

Ready to learn some essential core concepts and take your Cypress game to the next level?

Here we go! Here is a list of top lessons we learned and a bunch of advice that can help you onboard to Cypress quicker and make fewer mistakes than we did!

#guest posts #e2e #machine-learning