You Should Be Writing Tests

In the front-end space, while many acknowledge the importance of tests, I still encounter from time-to-time developers who believe that they're not always needed.

Maybe if you are working on a small hobby project consisting of one component and one screen with no routing, validation or anything else happening, that might be somewhat true.

If you are building a serious web application, consisting of actual functionality: avoiding tests is a one-way ticket to developer hell. As a bare minimum, you should have some unit tests and ideally a few integration tests as well.

As someone who has had to clean up a sizeable amount of messes left by developers who wrote terrible code, didn't write documentation and especially didn't write tests, it makes me clench my teeth whenever someone advocates for not writing tests.

Tests are documentation

Here is the beautiful thing about tests: properly written tests are documentation. A good test is like a story, it has a beginning, middle and end. It should accurately detail how a piece of code or functionality works.

Even if the Git commits lack detail, the internal wiki or Google Drive documentation is lacking, a test will tell you everything that you need to know. It will also allow you to refactor confidently.

Tests allow you to refactor unfamiliar code

How many times have you gone to change some code, and felt like you stepped into a murder scene? Horrific code all over the place, unnecessary abstractions (or none at all) and that sinking feeling in the pit of your stomach knowing if you touch this code, the house of cards might come tumbling down.

Provided the tests you do have are covering all of the critical parts of the code, you can go ahead and refactor code (to a high level of certainty) knowing that as long as the tests pass, the code is fine. That level of safety is something that not even the best documentation in the world can provide.

Even if something does break as a result of the refactoring, the likelihood of there being serious bugs, as a result, is lessened.

You don't need 100% coverage or test everything

This is a trap many newcomers fall into when getting started with testing, I have even encountered some senior developers who think like this. Aiming for 100% code coverage is useless.

What you should be aiming for is coverage of the critical parts of your application. Prioritise what is important, not what is the biggest and most complex functionality in your application.

Ask yourself the question: what parts of the app, if they broke, would have the most severe consequences for the business? Examples include authentication (ability to sign in and signup) and the ability for customers to purchase something (enter card details and check out).

You absolutely need tests, but you don't have to test everything. Not everything is critical. But, if someone tells you that tests are not important, politely smile and walk away because they do not know what they are talking about.

PS. Inspired by this post and some people who reached out to me, I published a brief little guide to getting started with test runners and frameworks here.