Unit Testing, a necessary evil?
Imagine yourself happily coding, in your own world, sending pull requests to the team for review, when a dreadful phrase comes up from the technical lead “We need to do Unit Testing”. Oh the pain, the anger and fear, “Is it really necessary?” you ask, just to get answered by a simple yes.
I think we’ve all been there in some time of our professional lives, being asked about doing the coverage of the code you just did and tested several times locally before commit, You’re pretty sure it’s bulletproof. I just can hear my QA friends laughing in the back of my head.
With time I’ve learned to like and respect this testing side of coding, I’ve seen the benefits of it in my own code over time. I must admit, I hated it too, going over and over again just to make some silly tests pass, trust me, with time you’re going to at least learn to respect them too, or not, that’s your call.
So why should we test our code?
I have to write code to test the code I just wrote? seems a bit redundant if you ask me, right? well yes, but no.
You see, making sure your code is well designed not only gives you an assurance, it actually reduces the amount of times the QA team could be sending back your user story because of some bug, to me that’s a big win; and let’s be honest, It’s pretty cool when the leads tell you ‘nice code’ after you submit a pull request.
A well designed code should be the standard, error management, strong typing, etc. These are things a well built unit test can help you achieve.
When is a good time to do unit testing?
Ideally before the testing phase, you can do unit testing before coding, while coding or after the project is finished, just hopefully before it goes to production, please.
Let’s get a bit technical, what is the structure of a unit test?
You’re going to find several testing frameworks, they all have one thing in common (Or at least the ones I know), They all follow the AAA pattern, not that AAA, It’s the Arrange, Act, Assert pattern.
This pattern simply put says, each step results in the input for the next one, assert(act(arrange())).
Arrange: Sets up the input or configuration you need for the unit you’re testing.
Act: As it says, execute the unit.
Assert: Verify that the result you got is the one you were expecting.
What cases should be tested?
At least the happy path, but to really be a pro, you should test not only that, but the sad path too, send some crazy parameters to your function and see what happens, what is it returning? is the returned result the one you were expecting? Is it failing? why? Do you have conditionals in the function, promises, observables, callbacks? are you testing all the paths your function has?
It’s not about just the coverage percentage, remember, you want to make sure your code is bulletproof and, fingers crossed, QAproof.
Unit tests are about code design
Most of the time a failing test or a code that’s getting really hard to test, are signs that the code is poorly designed and needs improvement.
A well defined function shouldn’t be so hard to test after all the needed configurations are set, well defined parameters should help you send the correct values to succeed.
This is a very simple example, but imagine having to test a callback hell or heavily nested conditionals, not so simple now, huh?
So, Which framework to use?
As they say, it depends, there are several frameworks available nowadays that can help you succeed with your testing, which one should you use? I couldn’t pin one down for you. All depends on how is your project structured, what UI frameworks you’re using, what language, libraries, components, architecture, etc, etc, etc.
The most popular out there would be Jest, Jasmine and Mocha. Jest is a very complete framework for testing usually implemented in React and in small projects, Jasmine also comes with a full content and is usually found in Angular projects since it’s already installed with Angular CLI, if you have a complex project maybe Jasmine would be the best for you; Mocha with Chai helps you a lot when testing the UI, let’s say you have a project with polymer components, that’s your guy.
At the end of the day it all depends on your project and your preferences, they all have pros and cons but something they have in common is that they will help you test, a lot easier, your code.
In conclusion, should you test your code?
My answer is yes, always, even if it’s boring, even if it takes you a bit more time, the benefits are something to take in count. Unit testing helps you code better, design better, have a better architecture, and you can be sure your code will do the task it is supposed to do.
So don’t be afraid of a few tests, if you find something to improve, why not? just improve it. We are in this world to learn and enjoy, remember life is what happens while you’re debugging and trying to solve the bug you can’t find.
Happy coding everyone! and see you next time.
