Migrating to Cypress, a journey

One year ago, we finished a one-year-long journey of moving away from Codeception and adopting Cypress as our tool to develop acceptance tests for Coolblue’s webshop.

Looking back as the person that led this process, I thought of this whole effort as “I only did my job”, but a deeper look and a conversation with colleagues reminded me that it was actually quite the challenge, and it motivated me to share what I learned during this process.

If you’re investigating adopting Cypress, I hope this blog helps you figure out the best way for your migration process. Enough introductions, let’s get into it.

First things first

Don’t get me wrong, Cypress is a great tool, I’ve been using it since its Test Runner got released as an open source tool, mainly for smaller projects and with great results, but that does not mean it’s the right fit for your project.

I was frustrated with how difficult it was to test our scenarios with Codeception, every time writing acceptance tests were mentioned during refinements a lot of extra points were added to a story and that just sat wrong with me, writing tests shouldn’t feel like a burden. That’s why I spent my learning blocks trying out how to make Cypress work for our webshop and first find solutions to fit how we handle different environments, countries and languages.

This first step was very important, I was able to find out how different it would be from my previous experiences using Cypress and gave me the space to find answers for our specific needs. Still, it wasn’t a 100% fit and half into the migration we had to deal with not yet supported features like SSO integration in different ports.

My advice is to check and make sure Cypress fits your needs first, or that you can find a workaround for these cases.

Get everyone on board

Here’s where I made my first mistake. Without previous discussions outside my team, I opened a big PR implementing Cypress to test a new feature and fairly, I received some very worried comments. This was never a one-person job and having everyone agree with the adoption of the tool first should have been my second step, so there I went: I collected data, arguments and went to our back-end and front-end meetings to get people on board.

At this moment you’ll hear some very reasonable questions, so listen carefully. Take your time to research and answer them. Getting input from my colleagues was absolutely important for the success of this endeavor.

They will be the ones creating new tests and maintaining existing ones, and getting people excited by the possibilities the new tool brings is as important as a perfect PR.

Measure, measure and measure

It’s only a webshop, right? Catalog, product page, cart and checkout. How hard could it be?
Well, we actually have multiple teams taking care of every page of the user experience in our webshop, which at that time meant more than 400 scenarios being tested and different people being responsible for writing and maintaining these tests.

Having a detailed list of scenarios was fundamental, it gave us a rough estimation of the size of the challenge, and it helped us to keep track of the progress of our migration.

The takeaway here is: make sure you have an overview of what lies ahead.

Let it go ❄️

Some development principles are beyond frameworks and languages, some are not. The limitations of previous testing tools had led us to create some patterns, like only having one assertion per test.

This example could have been valid previously, but how is this applicable for a test that is supposed to mimic a user behavior? Your user won’t load the page, click a button and reload again to interact with another feature, they also won’t wait 10 full seconds after a click for a modal to be open, so neither should your test, especially when having tools like Cypress with great error handling that will tell you exactly where the error lies.

In an effort to increase the adoption of the tool and the speed of the migration I added an extension to our Cypress implementation to allow for the usage of Gherkin to write the tests and at some point it only got in our way to make the best of Cypress performance and what the tool could provide, so we had to rewrite a good part of the scenarios for a second time.

Keep the compass in hand

Take this moment to not blindly convert every scenario to a Cypress acceptance test. Acceptance tests are costly and intrinsically flaky, therefore challenge people into asking if that scenario could have been covered by a unit or an integration test.

Cypress can easily be bloated with different types of testing, but in our case it was important to keep our goal in mind: making testing easier, decreasing the flakiness, and improving our day-to-day speed of delivery. Having that as our north guided lots of conversations into a common understanding and solutions.

Draw a map

Cypress documentation is one of those easy to read and follow. Fairly enough, some developers will only be interested in updating existing scenarios, and they will bring assumptions on how to write tests from previous experiences with different tools that in some cases won’t fit your new way of handling them.

Strive for making the adoption easier by developing custom commands if needed and writing a straight to the point documentation of what matters for your application.

Keep swimming

As mentioned before, it took us a year to complete the entire migration, and this is not to point fingers. We have stakeholders with new ideas to be implemented and so much time for task forces and contributing with the adoption of a new tool.

Bringing in some shiny new technology into a company doesn’t stop when the PR is merged, a good part of the job is to make time to give support to people that might be struggling with adopting it and to keep pushing people to make time for it, reminding them of the benefits of when we cross the line. Trust me, the trouble is worth it.

Enjoy 💃

And finally, when it’s all done, celebrate! This is web development, it won’t be too long until the next journey starts again ;)