There isn’t really a proper definition for unit testing other than unit tests test small units of code. How small is small? Generally speaking, it’s a class. When we write a unit test for a unit, we’re basically asking if this unit is fulfilling its responsibility and working the way it was designed. These are different from integration tests, which test how multiple units function together.
- Focus on test quality over test count
- There’s no magic number of tests you need to write for a project.
- Focus on good quality tests that will add business value rather than aiming for 100% code coverage
- Write unit tests for core business logic
- Don’t test libraries
- They provide huge benefits in terms of maintainability and longevity
Why I need unit tests?
- When written properly, unit tests can improve software quality.
- They make it easier to refactor code without breaking other pieces of functionality.
- They make code more maintainable.
- Since unit tests deal with small units of code, it makes it easier to pinpoint broken code after a build.
- They make it easier to identify bugs earlier on in development
- They can improve your overall code quality. The main reason being that unit tests force you to write clean code so it’s easy to test. Poorly written code can be harder to test
- When implemented correctly, they can reduce costs since bugs are found earlier on, reducing maintenance costs
How many unit tests?
This is quite a debatable issue. Some developers swear by unit tests and are determined to get 100% code coverage, while others hate the sound of the words. The key is to strike a balance. There’s definitely such a thing as too many or too few unit tests. But the answer isn’t so straight forward since it depends. I think a better question is…
When to write unit tests?
One rule that I apply when deciding when to write any test (not only unit tests) is to ask myself how much business value will this unit test produce?
The best unit tests you can write are the ones that test actual business logic or complex algorithms. Focus on writing high-quality tests rather than aiming for 100% code coverage and testing for that goal only. Poorly written tests will result in higher maintenance costs since you’ll spend loads of time fixing or rewriting broken tests. Remember, it’s better to have a few high-quality tests than having many poorly written ones. CBC
It’s easy to go overboard and write unit tests that are not very useful and don’t really add any business value. For example, if you have a method that performs one simple action like calling a library and returning the result.
// Example pseudo code that shouldn't be tested var client = new Client(); var result = client.getData(); return result;
Then it’s not really beneficial to test that method at all. A method like this wouldn’t be considered business logic. However, a method that contains core business logic should definitely be tested.
// Example pseudo code that should be tested if name field is empty or length is more than 250 characters return error; if description is empty or length is more than 3000 characters return error; var client = new Client(); var result = client.save(name, description); return result;
So, the more business logic you have, the more unit tests you should have.
I’ve seen tests that have been written to check that a library works the way the documentation says it should work 😬 The internals of a library should be tested by the author. As developers, we should consume a library and assume it’s working as expected. If you think that you need to test a library because it doesn’t seem reliable, then maybe you should be asking yourself if you should be using that library in the first place 🤨 The same applies to calls to your repository layer. There’s often not any actual logic in your repository layer, so it rarely needs testing. The ORM or tool you’re using in that layer should already be tested by the author.
But we’ve got legacy systems without unit tests and they work fine
This is often an argument brought forward in order to not write any unit tests. Although it’s great that an application is working fine as it is. An application without unit tests is difficult to refactor or extend without knowing if you’ve broken anything.
But it’s like writing double the amount of code
It’s not uncommon to work at a place that doesn’t understand the need for any type of testing. Of course, you should focus on convincing the higher-ups of the need, but to start out, it’s difficult to budget any time for tests. If you’re in this situation, leave…
If you have a good architecture in place and you’ve implemented good practices when writing code then tests shouldn’t take too much work to add. Implementing functional principles, and having a layer in your project that contains business logic will also help too.
The bottom line
These are just my opinions. Testing for developers is one of those topics that everyone has an opinion about. Some love them and some hate them. When code is written cleanly and is well structured, unit tests require little effort to write but provide huge benefits in terms of code maintainability and longevity.