You Should Be Writing Tests

beggars profile image Dwayne Charrington ・3 min read

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.

Posted on by:

beggars profile

Dwayne Charrington


Lead front-end developer @ ia // Aurelia.io core team, 11 years experience, amateur professional developer.


markdown guide

Great article. I totally agree with your reasoning, and am a big advocate for testing.

I'm really comfortable testing my backed code (PHP) so unit tests make sense to me. I really have trouble reasoning about functional tests for my Vue app (testing components etc). Can you point me to any good tutorials in this space?



I've just published a post which might help you on the testing front here. In terms of testing specific libraries like Vue, once you have your testing environment configured (usually handled by Vue CLI, I believe) you then will want to seek out specific testing libraries for Vue (or any other framework/library you are using).


Thanks! That was a helpful read on the tools. I think my issue is trying to figure out is when a component should be tested. And if there is a way to write components that's makes them more easily testable.

Ah, I have something in the works that will answer those questions. It's something I've been working on and off for a couple of months, it's almost done. I'll give you a buzz when I finish it off.


I agree with you 👍

I'm working as a developer for a small startup company.
I thought testing the back-end space was important, but the front-end space was overlooked.

We will test the important function of the front-end.


I agree 100% . Tests are so important specially at the moment of adding new features. Also because my current job is more back end that frond end , I like to use the coverage to show the current status of the project. (I already had that conversation with my manager that having a 100% coverage is impossible and not realistic)

btw:I was wondering if you could give me some tips on how do you test the front end ? I use selenium but many times I wish there was something faster