5 Tips to develop the habit of writing unit tests in 2019

Photo by Émile Perron on Unsplash

I have met and seen many projects and worked with many developers from all different levels. Some are used to writing unit tests, others don’t.

Similarly as we know that eating healthy, quit smoking and doing physical activity makes us healthier, we also know that writing unit tests makes a codebase healthy.

In reality, life happens and we not necessarily eat healthy, quit smoking or exercise. In reality, deadlines happen, project happens, and we don’t take the time to write unit tests.

But we also know that there are people who manage to eat healthy, quit smoking and exercise regularly, in spite of what life situation happens to them. We also know that there are developers who manage to write unit tests, in spite of a deadline or project.

I am one of both kinds, I eat healthy and exercise regularly, quit smoking 10 years ago and write unit tests regularly. So, from my experience on creating these habits, and practicing them for years already, I want to give you 5 tips that you could start using now to start 2019 writing perhaps more unit tests.

Tip 1: Start by writing the unit test directly after you identify the code that needs testing

When you have finished writing something that you know you need to test, don’t wait until you will do your PR or your code review to actually write the test.

At the beginning you will be slower at finishing a feature, but it will soon pay off. You will start notice that you:

  1. Get faster at writing unit tests
  2. Start noticing as you write it, code that is easier to test or harder to test
  3. Start writing by default code that is easier to test

Tip 2: Have a visual code coverage report and visit it often

Tools like Istanbul are really useful for developers, once you get the hang of it, it can become even addictive to write tests.

The thing is that using this is useful, because you have a visual understanding of the parts of your code that are not tested, branches, lines, functions, and also you see the percentage of code tested per file written.

For example, one of the components in my project has two untested functions. This is how Istanbul tells me which ones they are:

These two elements make writing unit tests more accessible to you, first because it becomes visual and second because you know exactly what you need to test, which for starters, is a good step.

Tip 3: Have a cheatsheet of your test framework at hand

In the era of quick access to information, we have the tendency to have in our memory a pointer to where to find the information, and not to have the information fresh all the time in our heads, specially if we are not using it often.

As you start creating the habit of writing more unit tests, you will need to have your cheatsheet always at hand. Once you start using it more, you will start to notice which functions you use more often, you will find them easier and at a point you will learn them.

There is nothing wrong of using a cheatsheet. The trick is finding one that covers with a simple structure the API of your test framework, so that you can scan it quickly and find what you are looking for.

During the last year I am writing unit tests with Jest, and this is my favourite cheatsheet

Tip 4: If writing a unit test is hard, then revisit the function you’re trying to test, and make it easier to test

This can be at the beginning hard to identify, the placeholder you need to keep in mind is: As you write the unit test, if you find yourself struggling or having a mental need of thinking about complex algorithms so that you can test that code, then it is the moment to revisit your function, split it in multiple functions, or just be creative and find different ways to simplify the code you want to test, so that is easier test it.

Tip 5: Get used to debug your unit tests

Sometimes you will be writing a unit test, and you will want to know what exactly happens in the execution of a function. In these cases you could go for our good old console.log, but a sometimes better alternative is to use the

— debug option of your test framework, but a breakpoint or a debugger statement somewhere in your function or unit test, run it through, and see what happens in the developer tools of your browser.

We tend not to use the debug option because we somehow put in our heads the idea that it will take longer and it will slow our pace down. If this happens to you, I can tell you that slowing down sometimes will make us faster.

Slowing down to debug your test, or slow down to read the standard or read the API documentation, will always pay off in knowledge, understanding and skill growth.

What do you think? Do you find these tips useful? Let me know in the comments!

Until the next