Recently at my work there has been a push to do more unit tests on the front end. There’s also been a lot of pushback: “Why do we have to unit test?” “This just takes more of our time that we could be using for feature work,” “Our automated UI tests will catch problems,” “Our QA testers are great, they’ll catch any bugs,” and so on.
Most of these arguments seem like compelling reasons to not unit test. Isn’t that just something that Java programmers do? Actually, unit testing in your JavaScript can save you time and headaches. Not only that, but you can look like a hero to your coworkers by reducing the number of test cases that they have to cover, either with manual tests or automated UI tests.
Not only that, but you’ll be a hero for whoever has to refactor or add things to the code that you’ve covered with good unit tests. There are few things more terrifying than having to go into old, crusty code to refactor it for performance or add features to it if there are no unit tests. If you break something, how will you know? Who knows how many downstream things depend on this code and its obtuse output? Will your testers (if you have any) catch things or will they not have time to do as comprehensive a regression check as this needs? Or will your customers come screaming complaining of a broken website, or worse, will they disappear without a peep?
You’ll also have a body of work that you can thank yourself for later: there are few better feelings than having confidence from good unit tests that you can refactor the code until it’s a beautiful shining example of clean code that would make a seasoned developer weep with joy. Wait, it still works, right? Well, the good unit tests pass, so we’re good to go.
Well-written unit tests can produce results that seem impossible for such a simple thing. It gives confidence to you that your code is working at a basic level. It gives confidence to other developers on your team that you’re looking out for their sanity and that you’re likely writing maintainable code that isn’t adding a ton of technical debt to the project. It gives confidence to QA that you’ve covered the basic scenarios and handled edge cases so that they don’t have to. It also checks a box that many in management are looking for and improves code coverage metrics.
There’s a huge number of reasons to unit test, but how do you get started? We’ll look at that next time.
