top of page

Why write automated tests?

When I first started coding for a living I didn’t write tests. I mean, I did test my code in the sense that I poked it and prodded it in various ways until I was happy it worked, but I didn’t write proper unit tests at all. The younger me thought that any time spent writing tests was time that should be spent writing more features, and anyway, we had a test team for all that stuff.

A toy car crash

The younger me was, of course, an idiot.

The older, wiser me knows that having a good, automated test suite is at least as important as the code you write, that it will make you a more efficient programmer.

Prove it works

As a developer it’s your job to prove your code works. It’s not your co-workers job. It’s not your product manager’s job. It’s not the test team’s job. It’s your job.

I mean, all the above stakeholders will almost certainly test your code as well in some fashion, but it’s up to you in the first place to produce code that works, reliably and repeatedly. And the only way to prove that is to write regression tests.

Tests are for your own protection. Each test you write, each new condition you verify, increases your confidence that it’s all Just Going To Work, that it’s not going to explode in flames when you least expect it, that you’re not going to have to work evenings and weekends to fix stuff that should have worked in the first place.

It means that the test team will stop nagging you about broken stuff that used to work, or edge cases that fail, or any other kind of unexpected nastiness.

Automate it

Having tests is one thing, but having them run on every code commit is the next level. I’ve always encouraged my teams to git push their feature branches frequently, partly because I’m paranoid about hardware failure (and yes, there’s a broken harddrive in my past that still gives me flashbacks), but mostly because it means the CI/CD platform kicks into life and runs the entire regression suite, and then pings them on Slack if they’ve broken something.

That means that any errors and regressions are caught well before they can really cause a problem: the most efficient time to catch an error is before the finished code has ever reached a human being. Most Git platforms will allow you to insist that the last test run succeeded before code can be merged to a release branch, which drastically reduces the possibility of screw-up.

Yes, test your UI too

I think most people would agree that writing tests for backend code is sensible, but far fewer would consider doing so for frontend code. With the advent of frameworks like and there’s really no excuse: it’s really very easy to write tests for your web app.

Automating those tests can be a bit trickier, particularly as your test suite grows. UI tests can be quite resource intensive, and a large set of tests may take some time to run. If you want to run the entire suite on each commit then the costs can stack up with traditional CI/CD platforms. Also unlike a backend test, a frontend failure is visual: you really want to see screenshots of the failed tests.

Having tried various CI/CD platforms in the past to try to solve this problem, I realised that none of them really worked well, and they were all so expensive. Which is why I created Cykubed.

Cykubed: CI/CD for Cypress

Cykubed does one thing but does it really well: it runs Cypress tests on a Kubernetes cluster. If you already run a cluster then installation is simply a few lines of code: if you don’t have or don’t want to run a cluster, that’s no problem either: you can use ours. Kubernetes is ideal for running resource intensive, massively parallel batch jobs like Cypress tests, and (particularly with using Spot VMs) is much cheaper to run than any standard CI/CD platform.

Cykubed has a generous free tier, so feel free to sign up and try it out!

40 views0 comments


bottom of page