This post was originally published on December 7, 2020 on my blog.
As I'm going through the motions of improving my coding skills each day, there's something that's always been on the periphery of my mind: testing.
Any job description throws it in. Discussions with well-meaning mentors and acquaintances drop the innocent assumption that you're correctly testing the code you run - you know, so that 'your linters dont' yell at you!'
But then I'm like, 'Whaaaaat?'
I'm not sure if I need to be testing my own personal projects or not, but I feel like it's probably a good thing to learn...eventually.
In the meantime, I found this great article, and it helped me start to at least make a little bit of sense of it all.
Any suggestions/recommendations/perspectives for a newbie tester are welcome!
P.S. I'm searching for my next role as a Front-End Web Developer! If you have any leads, please let me know!
My current tech stack: JavaScript ES6, React/Hooks, Redux, Firebase Firestore, Firebase Authentication, HTML/CSS, Git
Top comments (3)
I understand testing as the safety net around the code. It helps to ensure functionality.
Especially in a larger project, with different components being used in various places, a test can help avoid shipping bugs.
There are different types of tests. Since your post didn’t ask a specific question but rather perspective, I’ll attempt to write out mine.
Since I am a dev on a React app during my workday I refer to JS and React testing mainly.
The lowest level of tests are static tests like prop types and a linter. These are there to catch typos, ensure consistency in formatting and make sure you’re piping the right data through the right props.
Format on save is the bomb. No need to painstakingly count indentation levels or think about when and where to put a semicolon.
PropTypes are like in-file documentation when done right. What is inside that account object? Sure one could log it, check the dev tools or just scroll down and check the prop types.
One level up are unit tests, which test that your functions work the way you’d expect. I find that there a not that many of those in the front end. These are more on the back end to ensure that the business logic functions correctly, e.g. adding the correct taxes or discounting promotions.
Next up are integration tests or in React we should maybe call them component tests. These are to make sure that your components render as expected, e.g. is there a button on that form component? The button is an independent component but you’d be testing it integrated into the form component. Is the expected function with the expected data being called when I click it?
When testing a React project you want to write mainly these types of tests. My recommendation would be to look into testing library. It is a library to test the DOM and puts you into the perspective of the user. The advantage of testing like this is that it rewards you for writing accessible code plus makes it easy to switch out implementation while retaining functionality.
Lastly, there are end-to-end tests. These are to cover a whole journey or path through the project. These are to make sure that mission critical functionality is still working after you merged that new feature.
These might be overkill for a personal hobby project but are essential for any commercial situation. Who doesn’t want to avoid that customers can’t login anymore after you updated that form component that you are not sure about all the places that it is being used.
Testing is an important skill to have, since it can mean the difference between shipping a bug or not.
Plus TDD can be a productive way to develop, since it forces you to reason about your feature and your code in a way that would be hard to achieve without a test.
Jan, this is amazing — thank you so much for taking the time to write all this up. Very informative and definitely gives me a great overall view.
I’m familiar with PropTypes in React, could be a great habit to start getting into testing by adding those.
Again, thank you so much!!
One way to make that habit really stick is to set up ESLint to require PropTypes and implement a pre-commit hook with Husky to not allow commits as long as there are Linzer warnings. :)
In the beginning it feels really restrictive, but once you are used to it, writing out PropTypes takes a couple of minutes.