Before we start - I'm working on https://cloudash.dev, a brand new way of monitoring serverless apps 🚀. Check it our if you're tired of switching between 50 CloudWatch tabs when debugging a production incident.

Disclaimer: This post is a longer (?), better [citation needed] version of the talk I gave at JSHeroes 2019

The scene

Imagine.

It's Friday, 3pm. Sun is shining, birds are singing and even though you like your job you kinda-sorta want to go home already.

Someone stops by your desk and they say:

Hey, so I just merged that feature to master, awesome right? Anyway, I'm off to pick my kids from school, do you mind releasing it to prod?

Your heart skips a beat. And not in a good way. Of course you don't want to be seen as an impostor and you agree to release the code. I mean, what can go wrong?

Suddenly you're becoming ever more nervous. Why is that?

Luckily, science has an answer:

Question to you, the reader:

Are you okay with releasing your code on Friday? Why? Why not?

Ownership and balance

All human beings want to feel safe, it's one of our most basic needs (right after having a relatively fast CI pipeline).

If every single release to prod may lead to bugs, production incidents, annoyed customers or (even worse) spending long hours in regression test phase before any release this may very well lead to burnout.

(And not this one, that was my jam)

As a developer, I strongly believe in maintaining healthy work-life balance as well as having a sense of ownership of whatever you ship to your users.

At OLX Group we build websites that are used by millions of users daily. In classifieds business, having a production incident is equivalent to thousands of annoyed (to say the least) customers and lots of wasted money and time.

Members of my own family are earning extra cash by selling things on OLX.pl, if we screw up, their lives are affected.

Rise of the machines

In my career I've had an opportunity to work with a large number of development teams. In most of those teams, we attempted to cover our codebase with

🤖 Automated Tests 🤖

with a varying degree of success.

(If you don't know what automated tests (or e2e tests) are, imagine hiring someone who can type and click on stuff really, really fast and you tell them how to test your app)

Stability issues

Most tools we've used produced unreliable results. It was possible to restart the same test suite 5 times and get five different results. In some cases, the tests were passing only if Mars and Venus were aligned.

Having randomly failing/passing tests is actually much worse than having no tests at all. If you don't have tests, then at least you know that you're doing yolo releases.

Difficult to write, harder to debug

Automated tests are not meant to be DRY. If a test is broken, it should be trivial for a developer to open up the spec file and investigate what went wrong. Some of the tests we were writing were using Gherkin and while the idea was solid, the reality was... suboptimal.

Debugging tests should be easy as eating a whole pizza when hangover. Unfortunately, a large number of e2e tools forces you to go through thousands of lines of logs on Jenkins, Jarvis etc. just to find out that someone changed a label in the login form.

Enter cypress.io

God damn.

Cypress is the second (after jQuery) tools in Web Development I've immediately fallen in love with.

I still remember the meeting when one of our Engineering Managers at OLX wanted to demo this "new e2e testing tool". What I thought was:

Yeah, it's going to be the same crap but with different API

Then I saw this:

Let me quickly go through what you can do in cypress UI

• You get to see your test playing live
• There's a detailed log which tells you what's going on
• You can stop the test at any moment and the tested app is fully interactive and you can see how the hell did you manage to be logged in and out at the same time
• After clicking on a request, you can see the state of the app before and after the request fired.
• When developing the tests, every change to a spec file results in starting the test over. Did I mention that the runner is blazing fast? (it's blazing fast, FYI)
• Tests can be recorded and you get to check out both screenshots and video recordings from failing tests (or from passing ones, but I suppose that's not really interesting)
• Debugging? Just open up Google Chrome console, debug like you're used to.

The Dashboard

It's not only about the runner. At OLX Group we are also happy clients of cypress dashboard service which allows us to take a good look at the state of our tests and run tests in parallel which saves a lot of time.

Given the fact that in Poland we support multiple countries throughout Europe, can you imagine clicking through all that manually?

Why am I writing this?

Ever since we adopted cypress I know that I can merge things to master and go home.

Given the number of tests we have written, it's quite difficult to introduce a code change that is going to break our product. We are not perfect, our goal is to improve constantly but I personally managed to avoid a few potential production fucku... incidents thanks to cypress tests.

I get to sleep better at night, and I hope you will too.

Give it a try, I think you'll like it - I'd love to hear your thoughts on Twitter @tlakomy.

You know what they say:

Test your code, not your patience