Are Your Unit Tests Correct?

Most people, myself included, talk about unit tests as a way to "assure correctness". But rarely do we specifically think about what this means.

Let's break that down a little bit. When we say "correctness" what do we mean? Usually, we are talking about a specific algorithm or piece of functionality, and we are trying to determine if this part of our application is correct.

This is where some misconceptions may begin. Let's look at a couple of examples.

A common basic unit test example is to test an add method that replicates the addition operator… we feed in 2 numbers, and the function should return the sum of those 2 numbers.

So "correct" means that when we feed in 2 and 2, we get 4 out, and when we feed in 10 and 50 we get 60 out.

Next, something more real-world: in an order processing system, in the addToCart method, "correct" means that we add the item to the list of items in the cart.

Pretty simple so far. We know what "correct" means.

But do we? The problem stems from the add example when discussing unit tests. Most people would agree that the add function has one universally correct implementation because we are trying to implement not functionality per se, but instead, we are trying to implement math. In our minds, we focus on this math. So the idea of "correct" is obvious.

But let's look at our addToCart method. I showed a "correct" implementation above. Now, look at the following four implementations of the same function. Can you tell me which one is "correct"?

The answer is: it depends. It depends on the requirements of your application. For one application, you may require immutable operations. So the last one is the only possibility. Or you may require your cart to be sorted, so #3 is right, or maybe new items always get added to the front of the list, so #2. And the variations go on and on.

The other aspect of correctness that must be understood is that an algorithm is only correct RIGHT NOW. It MIGHT be incorrect tomorrow. This is due to either clarified or changed requirements. Applications always grow and new requirements and functionality are always added. This means that what is correct today may not be correct tomorrow.

Correctness in unit tests isn't a universal truth. Instead, it's about what is correct for YOUR application at this moment.

We have lots of courses like our Deploying Apps to Netlify course and our 100 Algorithms challenge. We have a couple of new courses about to drop as well.

And don't forget to check out all our awesome courses on JavaScript, Node, React, Angular, Vue, Docker, etc.

Happy Coding!

Enjoy this discussion? Sign up for our newsletter here.

Visit Us: thinkster.io | Facebook: @gothinkster | Twitter: @gothinkster