Piece of Mind: Testing

#testing #frontend

Welcome to this series of articles Piece of Mind.
In these articles I will just tackle the surface of subjects I care about and what is my thought process on them. They will hopefully bring you to reflect and maybe research them in order to grow your own ideas and practices on them.

Testing your code is a very important step in your developer journey. Unfortunately, a lot of people think it's useless and/or don't need that much consideration while coding. I often see code badly tested (false positives, unreadable tests, etc...) when it should be a priority to the project.

Anti-regression

When updating a codebase, especially a big one, you can't always guess what your changes will bring.
Let's say you have a slider with a blue button on the first slide and a yellow button on the others.
You are now asked to change the last slide button color to green.
You add one line of code there, remove one here, you compile and launch the project to visually test that the last button is green.
Everything's perfect, you have done your job, and the project manager will be happy to see their green button.
But at the next meeting, the project manager is not happy ... they (or the QA team) found that the first button is no longer blue. You completely missed that when you checked for your modification on the last slide.

Well it wouldn't have happened with tests (ok ok it still happens ... but a lot less !)
With correct tests, you can catch regressions before they happen.
If a test says "On the first slide the button should be blue" and another says "On every page but the first one, the button should be yellow" and after you update the code the first test fails, you know you broke something and can quickly fix it (and you also know you should update your tests to add a test about the last button).

Project comprehension

Good tests can be an awesome tool for project comprehension. Sure you can read all the codebase and have a pretty good idea about what's going on, but not everyone is capable of that and anyone can miss some points.
With well-written tests, you can just read the test descriptions to know what was asked of the developer.
Without reading any code, you open the tests for the button from the previous example and you read :

First test: "The button is blue on the first slide"
Second test: "The button is yellow on all slides but first and last"
Third test: "The button is green on the last slide"

After 3 lines you know exactly what this component is all about, and what is expected of it by UI/UX/Business

TDD (Test Driven Development)

The 3 big letters of testing! You surely may have heard of it before. TDD is a way of writing tests for your project. Basically you write tests BEFORE you write code. The tests obviously fail, your job is then to make them pass.
This is a great way to work because you just have to translate what you've been asked: just write down as description what is expected ("The button is blue on the first slide").
The big downside, at first, of this process is that it's hard to work like that on a technology you're not used to yet or when you begin to learn how to write tests... Once you got those two requirements, try TDD out =D

Ideas to go further :

https://kentcdodds.com/ : Kent C.Dodds is a software developer that is passionate about testing and testing good practices. Even if his talks/articles are mainly about front-end development, any developer can learn from him.
A great article about rules to follow to create great tests in your projects.
For JavaScript developers: a nice article that compares some testing tool. Because it's important to choose a good tool for a job.
Nice tips for writing good test descriptions by Yahel Yechieli.

A special thanks to Rudy Weber for helping me writing this piece of mind.