Why Run Tests Locally?

Why Run Tests Locally?
Photo by Priscilla Du Preez on Unsplash

To verify that our code works before we commit it.

Why not just commit and wait for the CI to tell us if we passed or failed?

Because it is slow and interrupts developer momentum. This combination of slowness and interruption to your flow is extremely costly for productivity.

Here is the process.

First off you need to get your code ready for a commit - clean it up etc. Then you push to your branch (hopefully you aren't developing off master and pushing untested code) . You then wait for your job to get picked up and run. The delay before starting your test run can be significant and then your test run is slow and takes another 5 to 15 minutes (or much longer in some cases).

This all has to happen before you can merge your feature and finish what you are doing. You'll then need to check back in from whatever you've been working on in the meantime and merge your code.

All of these changes in task and focus are the enemy of productivity. Each context switch is an opportunity to get distracted by email, social media or a trip to the coffeeshop.

If however your tests fail you need to fix the code and restart the process. As experienced devs know, this can often just be a configuration flag you forgot or something else trivial, but you need to go through the whole slow process again in any case.

If you could just run your tests locally before you commit, you'd know that they worked and could skip a whole bunch of distractions pushing code with confidence.

However, test suites have grown to be massive unwieldy beasts that will melt a poor unsuspecting developer's laptop if you even try to run them locally - and that's where Brisk comes in.

Brisk massively parallelizes your tests from your terminal to our servers so you can get the benefit of running local tests with the power and scale of the cloud.