Writing unit tests is certainly a good software development practice, however there are a number of things we should not actually test when writing unit tests. These include…
The framework
Do not unit test any frameworks you are using. Unit testing an external framework is the author of the framework’s job, not yours. You should instead expect the framework to work as expected.
public class Customer
{
public string Name { get; set; }
}// ...[Test]
public void WhenNameSet_ThenCanGetName()
{
var sut = new Customer();
sut.Name = "John";
Assert.That(sut.Name, Is.EqualTo("John"));
}
Consider the simple C#/.NET code and test above. The author creates a Customer, sets its Name property, then checks that the Name property contains the string value. This unit test is not really testing anything useful and is instead testing .NET itself!
(I have seen tests like the above in the wild and suspect these sorts of tests are a bi-product of dev teams that are simply trying to get their code coverage metric up.)
Points of integration
Points of integration to other systems should not be included in unit tests. For example…
- Anything over IO (e.g. reading and writing to disk)
- Anything over the network (e.g. integrating with a web API)
- Anything that connects to a database
Testing points of integration to other sub systems is slow and we want to keep the speed of our unit tests fast. That’s not to say these kinds of tests don’t have value. They should instead be covered by other types of tests such as integration tests or acceptance tests which can be run separately from our unit tests.
If you find you have integrations points to other systems in the code you are trying to unit test then these dependencies should be stubbed out in your unit tests.
Internal types
An internal type is one that is accessible only within the assembly (exe/DLL/etc.) it is present in. Though on occasion it can be useful to unit test an internal type we should try to resist the urge. This is because we should be unit testing through the public contract of our code so our tests do not become tightly coupled to the internal implementation details (see my post “Things I’ve learned from writing a lot of unit tests” for more on this).
However, if we do write unit tests for internal types once we are happy the production code is doing what we expect then the tests should ideally be deleted.
Tests
Tests that test your original tests. If you have reached this point then something is very wrong with your original tests. It’s very likely that your original tests have become complex. Try to keep unit tests simple (avoid condition statements like if and while) and never write unit tests that even call other unit tests let alone test them.
