8 Signs You Should Invest in Unit Tests

A lot of us are quite busy in our jobs, meeting challenging project deadlines, changing requirements and juggling production support issues/bug fixes as developers, so sometimes we end up skimping away on the unit tests that we really know deep down we should write. Here is a list of 8 signs which if you see in your code, its time you need to start writing those unit tests! If you need a quick primer you can find it in our Guide to Unit Testing Part 1.

Sign #1 You are beginning to have large number of lines in a single source file.

Usually this is an indication that code isn’t modular and lacks testing coverage which will make it that much more difficult for a new programmer to start working on the code.

Sign  #2 You are spending a lot of time trying to debug code issues.

With unit testing you considerably reduce the amount of debugging that you need to, because a lot of the test cases can be tested at a class level, so the behaviour is somewhat predictable.

Sign #3 You normally have to run the entire software stack, in order to test a small piece of implemented functionality

Modern testing tools have made it a lot easier to mock external services/components and more often  than not a unit test level code is sufficient to give you confidence as to whether the feature will work as intended (or not!)

Sign #4 Your testing normally happens once you have completed all the development

Test-Driven Development (TDD) mandates that the tests are written prior to the implementation. I don’t necessarily adhere to this all the time, but every time I have written my tests first, my code has been precise, decoupled, modular and easy to test as opposed to writing tests after the class has been written. If you are writing your tests after you written the code, then chances are you might not have the incentive to complete writing the tests, since the code is already written!

Sign #5 You think unit tests are a waste of time, and writing them reduces time for delivery!

This is actually one of the most common reason developers cite for not writing unit tests! Beware! For thinking like this is a trap. The entire reason unit tests exist is to provide a way to test formally the delivery of the code that is written. Unit tests are executable functional specifications. Without them, there is no quick and easy way of telling whether the code that is written is indeed doing what its specification says its doing. Investing in writing in unit tests actually, give greater assurance to you and your customers as to what level of functionality has been developed, and can be immediately tested by running the test suite. Without them, you would still have to test the software manually(!) every time a change is made, introducing the possibility of more bugs creeping into production which could have been caught, if unit tests were written.

Sign #6 Your Continuous Integration Environment is almost always RED OR You don’t have a Continuous Integration Environment

This is one of the most prominent signs that your code is suffering from ‘code rust’ and people aren’t bothering to fix the existing unit tests, no matter writing new ones! The value of CI environment is to provide indicator if there are any tests failing, and if so, must be immediately fixed by the team at a priority. It loses value if the team starts ignoring it, because then you have area(s) of software that aren’t working properly as indicated by the failing tests. If you don’t have a Continuous Integration environment, then you should strongly consider investing in setting this up. There is a short guide to setting up CI environments here: Guide to Setting Up Continuous Integration

Sign #7 You don’t use any code coverage tools or have very little code coverage

Code coverage tools provides a visible metric for measuring how well tested a codebase is. Ideally having 80% or higher coverage indicates a good unit testing discipline. Prominent Software thought leaders such as Uncle Bob Martin recommend a greater than 99% coverage! So its good to start using code coverage tools if you haven’t done so already.

Unit Tests Coverage

Sign #8 Your unit tests normally require external system dependencies (e.g. Databeases, Webservices, Messaging Systems)

It is easy to fall in to the trap of thinking that you are writing unit tests when in fact you maybe writing Integration Tests instead! Integration testing has its place, however, when you are unit testing, these external dependencies must be stubbed or mocked.

I hope this article would have convinced some of you to consider introducing tests in your code!