End-to-end all the things: using Cypress in Spaces
A lot of psychology practices teach that you should learn how to rely only on yourself, take care of yourself and continue practicing this learning throughout your life. Why? Because it simply makes you a strong, mature and stress-resistant individual. And it’s a fair point. However, living in a modern world anyway makes you dependant on some things, so you learn how to manage those dependencies by gaining goods or tackling the problems caused by them.
The same learnings about taking care of yourself and not relying on anybody else can also be applied to software. In a way that you learn how to take responsibility for your work. For example, after developing a new feature, you want to check that everything works just as you expect it to. And you can easily achieve that by writing tests.
As a web developer or any other part of the software engineering process, it’s crucial to take care of features, bugs and whatever you are creating during development. And it’s also crucial to have ownership and feel confident your code won’t cause any issues in production.
I shouldn’t need to mention that web development is not an isolated world. There are tons of dependencies (insert npm jokes here) included in every project and it’s totally fine. While working on the frontend part of your project, you most likely dependant on the backend part. To have a new feature ready for production, you need to make sure your frontend is nicely connected to the backend. And most important is that user flows have no issues. This is exactly where end-to-end tests come to the rescue.
I joined N26 as a web developer in June last year. The team I was assigned to was working on Spaces, which were just about to launch. A few end-to-end tests for critical paths already existed. I was curious to learn more about testing and it was my very first introduction to Cypress — an open-source, Javascript end-to-end testing framework for “anything that runs in a browser”. Cypress has a gentle learning curve, especially if you’ve worked with jQuery before (shrug). A few lines of assertions and checks and your first test is written. And it just runs so beautifully in the browser!
Right after the launch, we started to work on Spaces details feature, that included transactions inside a space. A new version of Spaces was being built on top of the existing one. During the planning of new features, writing end-to-end tests became a part of almost every story by default. This was essential because tests helped us a lot to avoid potential bugs. And it was so easy to write them! I got hooked pretty fast.
Together with our Quality Engineer, we developed a system which later on made our release process much faster during regression testing. We separated test cases into 3 categories: UI, data and end-to-end. Within the UI, we had to check if all elements were present on a page. For data, we had to check that all data on the frontend corresponds to what is coming from the backend. For end-to-end, we had to test actual user flows.
As we tend to keep our test accounts clean we usually restore defaults in “before hooks” from Cypress. To achieve the clean state of accounts we would need to remove all the data created during the test run, which means we would have to make more API calls. For UI tests those calls were unnecessary. Therefore, moving UI into separate test blocks helped to reduce the number of calls to the backend.
We used this “separation of concerns” technique in our test cases. Each testable feature would have two separate files: one for UI related steps and one for data with end-to-end.
By the time the release date came, we have covered all the critical flows. The number of tests cut regression testing time in half as we automatically passed everything covered by end-to-end tests. I was super confident that the Spaces release would be smooth thanks to the tests.
Moreover, with a hyper-growth mindset, more features are being worked on and refactoring takes place on a daily basis. This is the exact case when tests also save you from breaking things. We experienced this while working on the new Spaces transfer flow, which was a complex task. It was also quite time-consuming to cover it with tests, but we did it and actually found a few bugs during further refactoring. It was at this point in time that I got most excited about having so many tests written.
One more thing Cypress tests can give you is a kind of documentation. By running tests in the Cypress desktop app, you can see all the main use cases for your product, which can be quite useful for onboarding new engineers.
Only half a year ago I learned about Cypress for the first time and now I feel my life as a web developer would be incomplete without writing end-to-end tests. It became a lifesaver.
Interested in joining one of our teams as we grow?
If you’d like to join us on the journey of building the mobile bank the world loves to use, have a look at some of the Tech roles we’re looking for here.
