The term ‘Unit test’ describes a unit of work that should be tested: One lightweight test of one unit of work.
Lightweight means they are fast, easy to read and write, repeatable, and therefore consistent.
Note: Unit tests need to be independent of each other If Unit tests build on each other (aka need the certain sequence to run successfully), this is a recipe for disaster and chaos. Unit tests need to run independently.
Note: Unit tests need to be trustworthy A Unit test need to test what it says and fail reliably when outside of operational parameters.
Note: Unit tests are code They can be refactored and need to be read/maintainable.
We listed some very good further resources in the section below, from now on we will focus on Unit tests in Debugging especially. We also cover how to react when discovering bugs by unit tests in development in 3.2.
We suggest building a solution strategy first (see 2.2.1) - aka you experimented and you have a good idea how you gonna solve the issue at hand. Then check what is missing on a unit test side of things and add or change what is needed.
There are a variety of testing frameworks available and most of them do what you need them to do. We found the following criteria helpful:
This is a pretty common situation: Test coverage is next to or exactly zero. Now you need to make a guided decision whether to do something about it or just leave as is.
The first frog to swallow: You cannot reintroduce Test Driven Development after the fact. Decisions on the implementation have been made. In general, trying to write Unit Tests in bulk for legacy code does not make sense. You tend to test the code as it was written (instead of what was intended to be done). So aftermath unit tests seem to test the most obvious things returned by the code anyways.
On top, you can obviously use Test Driven Development for any new code. See our later article on this.
But Unit Tests can help you in debugging: You can add tests to reflect extreme cases or add fuzzing to already existing code you suspect to be wrong. It frees you from debugging the whole system just to inject a few data points. So, using unit tests (and mocking) might save you a lot of time (and even better), makes your debugging tests repeatable and packageable.
Unit test are a valuable tool but reintroducing TDD after the fact is next to never a good idea. Rather, use them for all new code.