Unit testing is all about testing the right things
In a series of short posts I am identifying some key attention points in delivering top #quality products to your customers. This second article is about unit testing and one particular aspect of that: picking the right thing to test.
Unit testing can help you deliver better quality products to your customer. The software will be more stable, robust and new developers on the project will not be able to introduce new bugs due to being unknown to some parts of the system. It is a safeguard against future problems.
It is also a great way to support your refactorings of your code. Refactoring will happen, many times during the lifecycle of your code. Developers will restructure code, introduce new sub and super classes and will refactor existing code into services (or vice versa).
There is one important thing that developers some times need a bit of time and experience to get inside their head: testing the right thing.
One of the goals in a project might be: get a high code coverage percentage (the percentage of code that is covered by your unit tests). Tools like Visual Studio provide you with measurements of your code coverage and developers and project managers might be proud of getting a 100% coverage.
But, more important than your 100% is what you are testing. Let’s give an example that I once used in a presentation on this subject. This example was based on the things that I noticed in the unit tests before I came on board.
This sample tests a MainService object that we created and which as a Run-method, which takes a string parameter. We expect this method to do some validation and add the item to the data repository using the method it provides.
Some might test this by setting up the AddRecord method of the data repository service and test if the item is added to the repository. Seems light weight, fast and robust.
Note: I am using FluentAssertions (https://fluentassertions.com/) in my unit tests.
But, what are you really testing here? Is it your code or are you testing the capability of the Microsoft stack to add an item to a list? Trust me, they know how to do that.
If you are testing your code, the only thing you want to know if your code called a particular function of a service, not if that service did its job. It has its own tests for testing that behavior.
This is how you want to test your code for correct behavior.
We setup the AddRecord method (otherwise we can’t verify it), set up our service, call the method we want to test and then verify if during that run, the record we expect is added to the data repository.
Nothing more, nothing less.
Don’t worry about the inner working of the dataRepository implementation. You should trust that it does its job. If you are testing your code, it is sufficient that you verify the calls to services you are using.
If you want to test for error situations (like a database not being available) set up your data repository differently and test if you code handles that as expected. Something like this:
So, keep in mind that it is important to test your own code and your own code only. Mocking and proper assertions will help you do the job. Whenever you use Callback in your mock-based unit tests, think again if you really, really need it. You probably don’t.