Have you written unit tests only later just to find out they really slow you down because your changes cause a lot of test breakage? Do you think these tests fail to meet the promises you’ve heard? Don’t dive up and read a little to find the benefits of unit testing.
The clue of unit testing is to write tests which exercise the smallest “unit” of code possible. Unit tests are typically written in the same programming language as the source code of the application itself and written to utilize that code directly.
Think of unit tests as code that tests other code.
When using the word “test” here, you should remember that unit tests aren’t really tests. They don’t actually test anything. When you run a unit test, you don’t typically find out that some code doesn’t work.
It’s when you write a unit test that you find that information out.
Yes, the code might be changed later and that test could fail, so in that sense, a unit test is a regression test. In general, however, a unit test is not like a regular test where you have some steps to execute and you see whether the software works correctly or not.
As a developer writing a unit test, you discover whether the code does what it is supposed to or not, while you are writing the unit test because you are going to be continually modifying the code until the unit test passes.
The Value of Unit Testing
Why does unit testing have so many sticklers? What is the harm in calling unit testing real testing and not testing the smallest unit in isolation?
Well, let’s see and try to find the answer.
There are two major benefits, or reasons, to accomplish unit testing:
- to improve the design of the code
When you write proper unit tests, where you force yourself to isolate the smallest unit of code, you find problems in the design of that code.
You might find that the basic functionality you are trying to test is spread out across multiple units, and that might make you realize that your code is not cohesive enough.
You might find that you sit down to write a unit test and you realize that you don’t know what the code is supposed to do, so you can’t write a unit test for it.
And, surely, you might find an actual bug in the implementation of the code as the unit test forces you to think about some edge cases or test multiple inputs which you may not have accounted for.
By writing unit tests and strictly adhering to having them test the smallest units of code in isolation, you find all kinds of problems with that code and the design of those units.
- to create an automated set of regression tests which can operate as a specification for the low level behavior of the software
What does that mean?
Regression testing is much more effective at the higher level as a black box testing activity because, at that level, internal structure of the code could be changed while the external behavior is expected to remain the same.
Unit tests test the internal structure, so when that structure changes, the unit tests don’t “fail”. They become invalid and have to be changed, thrown out, or rewritten.