Why back-end?

It reveals bottlenecks at the component level
Shift-left and modularity
It replicates behavior under load
Better failure handling

If back-end testing is like the kraken hiding underneath the surface, and if it’s more difficult to test, why is it worth the effort? Here are some benefits that back-end testing gives beyond front-end testing.

It reveals bottlenecks at the component level. Front-end testing tweaks the end result, the nice UI that will ultimately be interacted with. But which application components exactly are slow, and why? Front-end testing typically won’t be able to answer that. Maybe those elements are all being hosted on a server that is underpowered or overutilized. You’re not going to be able to pinpoint that by just looking at requests in a browser. That stuff is hidden from our customers on purpose– we don’t want them to see all the mess!
Shift-left and modularity. Applications begin as code, and that usually means starting without a UI. Without the UI built, front-end testing can’t be done, but back-end testing can– so this means you can test earlier in the development cycle. In fact, ideally your developers are also writing unit tests for performance. The earlier that performance defects are spotted, the easier and more cost-effective it is to fix them.

Back-end testing lets you be more granular, in that you can target just one part of the application that is built. You don’t need the entire application built to do back-end testing, and you don’t need the whole environment. If an integration with another component hasn’t been built yet, you can still test the component that IS built, mocking up responses it would expect to receive from the other component that ISN’T built. Back-end testing lets you do system testing as features are being created.

It replicates behavior under load. Front-end excels at optimizing a single user’s experience of an application. You CAN use front-end tools to load test the back-end, too, but those tools are typically very resource-intensive by their very nature, so it can be significantly more expensive to do that.

We spend a lot of time making sure that the test environments we’re using for our tests are as close to the real thing as possible: we want the same application logic, the same interface, and the same integrations. But load is part of that, at least for most public-facing applications. Back-end testing lets you see how the user’s experience degrades when there are many others doing the same things at the same time. It also lets you see how well your application responds to that increased demand. It’s like the ultimate dress rehearsal.

Better failure handling. It’s hard to induce significant failures in front-end testing that affect ALL or most users, because if we can induce it at that point, from the interface, then so can our users! In back-end testing, the access we have to the things “under the hood”, so to speak, let us also run more interesting experiments on our application. We can purposely create catastrophic scenarios to see how quickly or gracefully the application recovers.

Back-end performance testing also helps us identify issues that arise from structural or architectural decisions. Maybe we should consider using a Kubernetes cluster for a particularly vital part of the application, or maybe we should use a CDN to distribute our resources instead of serving them directly from our application servers in one country. Back-end testing lets us test assumptions about how the application is built and gives us data to decide whether or not we want to change it.

So if back-end performance testing is so valuable, why don’t more teams do it?

RIGHT.

Many people don’t do performance testing because they’re afraid of this (meme) happening. It comes down to one of four things:

We don’t have the time.
We don’t have an environment (and performance testing might burn down the house).
We don’t have the expertise.
We don’t have the money!

In my demo I’m going to challenge these assumptions. But first, let me challenge a common misconception that I think is at the root of these assumptions. When people say “performance testing”, they really mean “load testing”.

Load testing is a subset of performance testing. Marie has already spoken about how front-end performance testing is a different and important part of a performance testing strategy. Even within back-end performance testing, though, there are tests that we can run without applying significant load.

Demo

Myths busted

We don’t have the time.
We don’t have an environment.
We don’t have a load testing expert.
We don’t have the budget for that.

If we go back to the assumptions that prevent teams from doing performance testing, I think we can definitively say that they are myths we’ve busted.

We don’t have the time. I created a performance test live in under 20 minutes, so it’s clearly not a matter of time. Sure, there are more things you can do to improve the coverage of your performance tests, but something is better than nothing!

We don’t have an environment. You don’t need one! Everyone has a production-like environment, and that’s production. If that’s the only environment you have, start with running smaller tests more frequently, like ones that are tied to a CI/CD pipeline so that you get historical trends. You can spot performance degradation even with 10 users.

We don’t have a load testing expert. You don’t have to be! Anyone can run a load test– that’s why tools are so important. Choose tools that empower you to run tests right away, and you can learn and improve your skills along the way.

We don’t have the budget for that. Luckily there are many, many open-source tools, including k6, that don’t require you to have any money. Even if you do want to pay for extra convenience, it’s $59/month for simple tests, and it’s ok to never increase beyond that, because you’ll get a lot of value for those performance tests.

DOWN.

Marie Drake
Twitter: @mcruzdrake
Site: mariedrake.com
Slides: slides.com/mariedrake

cypress.io
Google Lighthouse

Nicole van der Hoeven
Twitter: @n_vanderhoeven
Site: nicolevdh.com
Slides: slides.nicolevdh.com

k6.io