In today’s article we’ll be diving into the topic of testing our new and existing code; we are going to explore some interesting aspects of this process. This post will be a starting guide whether you are new to unit testing or just looking to deepen your knowledge on the topic.

Chances are you have been in the following scenario or at least heard it happen a couple dozen times to someone else: Company X is pushing to deploy a new product or feature to the market, the end of the quarter is nearing, last minute changes from the Product team or clients are lurking just around the corner and you find yourself in the age-old dilemma of software engineering; asking yourself if you really should risk quality code over quantity deliverables.

When all is said and done, product/feature goes live, everyone is happy – and then the flock of users reach the new software capability. With each key press and mouse click the user the chances of finding a new bug in the system increase. All of a sudden, BOOM. Numerous alerts and logs coming in from Sentry and Mezmo:

Could not read property of undefined

Expected Int but received a non-integer value

Server not responding

While you are digging through the logs and stack trace of exceptions, one question keeps burdening you all the time: what could we’ve done better to avoid these runtime errors?

To be fair with myself and everyone in the community; avoiding or preventing bugs in production is rather a difficult task to be done, but with the right amount of effort, best practices and principles we are able to reduce the margin of error by quite a lot!

Imagine if there was a perfect codebase that would ‘almost guarantee’ your software to be bug-free (or at least less buggy) – sounds awesome right? Well, there is something that can bring you quite close to that state of happiness. Unit Tests.

Unit testing has been around since 1997 with a solid solution being used at the time which was called JUnit and it was very familiar within the Java Development Community. From that point up until now, this aspect of software development has been improving on a daily basis with new tools and libraries to help you reach more than desired results whenever testing your codebase.

In essence, you want to unit test almost every single line of code in your codebase (not everything though – we will dive deeper into this further down the article). Through unit testing, you are constantly fighting your own solution to do the right thing no matter what and when it stops doing that you get notified before it reaches production. Because of this practice, we assure ourselves that we are refactoring our code and writing even more clean code to our solution.

But, having test cases and test suites in your codebase has another big blessing in disguise

I’ll ask you a question: how many times did you have to ponder down legacy code trying to figure out what the heck the developer wrote in the business logic five years ago? The unfortunate thing here is that you can’t even ask that developer since they are no longer part of the company and everyone else is a bit scared to even go in that file.

The idea here is that, through unit testing are we not only capable to deliver quality code which is robustly tested to do the thing that is expected from it to do; we also achieve a perfect situation for the team where we document our business logic through unit tests. Having test cases with clean descriptions and ‘asks’ we are able to quickly understand the underlying business logic.

Let’s dive into some best practices of writing unit tests in our codebases >