Never skip writing unit tests!

"I don't see why we need unit tests - this is a simple logic, I know it works" - a quote from too many developers.

The benefits of unit testing won't be evident immediately, but you'll only notice the impact down the line. Let's briefly discuss why we shouldn't skip writing unit tests whatsoever - even if you test it manually.

If you don't know what unit tests are, it might be because your team doesn't follow unit testing or find any need for having unit tests. Then this blog is perfect for you! Explore more on unit testing and how to add it to your codebase after you read this article, and hopefully convince your team on it's importance.

In a one-liner - unit tests are tests which ensure that each component of your application works as intended, as an isolated unit. You write tests to simulate scenarios with assertions to ensure that smaller parts of your code do what you expect it to do.

The misconception on the need for unit testing usually arises here - "If I can just try out scenarios manually why bother wasting twice as much time writing a test for it?"

It's not for you#

Unit tests are not meant for you - the developer working on the feature. It's meant for everyone else but you!

There's partial truth to the above sentence. Unit tests definitely help you, the developer, ensure that all cases are covered clearly. But, the main goal of unit tests, in my opinion, is to be your first point of failure when writing code. It should help you regress as soon as you realise something you wrote is breaking something you never intended to affect.

A unit test suite should tell every other developer how your code is expected to behave, and - just as importantly - how it should not! Testing only the happy path of your logic won't help others know how the code is expected to behave in other scenarios.

But my other tests already handle these scenarios#

Great, the more thorough your testing pyramid is, the better. But then again, you might want to rethink - are you segregating the responsibility of your tests correctly? Are your system tests trying to verify what your unit tests should be verifying?

There's a huge variety of tests that can be run on an application - unit tests, integration tests, end-to-end tests, the list goes on. Read up on Martin Fowler's blog on Practical Test Pyramid to get a deeper understanding of what tests should be responsible for testing what parts of your solution.

In short, your unit tests should be testing out a much larger part of your business logic at a very granular level - other heavier tests should not be overburdened with the responsibilities of the very light-weight unit tests.

If you see your software plagued with frequent bugs, issues and failures, rethink your test strategy. Unit tests should be the first point of failure for your components, before something becomes a bug.

Ok, I'll write tests#

But wait! Another common practice I have seen is having tests with no value. These tests make your codebase look shiny, the coverage would have hit 99% or more! Alas, even if someone else changes the code your tests still pass.

Mutation testing is a great way to help identify how much your test suite is just bringing up coverage without adding any value. In mutation testing, a tool simulates a developer coming and changing your code. It mutates your codebase to try and purposely fail the tests - if the tests don't fail it's (usually) a bad sign and gives you feedback of holes in your test suite. Read more on Mutation Testing in my blog post.

Test Driven Development is another great tool that helps you write more meaningful tests. It helps ensure that you think about what your test is going to do first before writing the logic. TDD is enabled using a technique called the Red-Green-Refactor Cycle. During your development of a feature, instead of diving straight into the implementation, TDD emphasises the following flow.

Combine both and you'll be having a codebase that has far fewer bugs than before.

In conclusion - if you ever find yourself questioning why you need a unit test for some code you are writing, you might want to retrospect and find out why - should you improve your test strategy or your test suite?

Till the next post, poka poka!