Due to popular demand, I’ll be writing a bunch of posts on unit testing.
In this post I’ll introduce unit testing: What it is, when it’s a good idea and when it might not be. I’ll also discuss a bit about what makes for a good unit test.
Next week I’ll post a followup to this, which will be more about actually writing unit tests with examples.
What is unit testing
If you are already familiar with the concept, you may wish to skip this chapter.
Simply put, unit testing means writing code to test other code. There are a variety of libraries for testing for various languages: for PHP there are PHPUnit and SimpleTest, for Java there’s JUnit, NUnit for .NET Framework languages, etc.
The idea is that when you write tests for your code using one of these tools, you can easily automate them and run them as often as needed. By writing unit tests, you can easily ensure that your code works as expected, even if the code is later changed, as your tests stay the same and you can (and should) always run them after doing changes.
There’s a good article on unit testing in wikipedia, which you should check out for a more in-depth explanation of it.
When is unit testing a good idea?
There’s a short answer to this: Always.
And there’s also a long answer to this: It depends on how complex your project is, and how long is its estimated lifetime.
If you have a very simple project, writing unit tests for it may take time that would be better spent in just writing the project itself. If it’s simple, it’s less likely to be difficult to test and it’ll be easier to find errors by manually using it.
If your project’s estimated lifetime is short, you may again want to not spend time writing tests. If the lifetime is short, you usually won’t have to maintain it or do any changes to the code, making unit tests less beneficial.
That being said, if you have the time and resources to write unit tests for even small/short projects, it may be a good idea. It largely depends on the situation, and you should make the call based on your specific circumstances, but the two cases I mentioned should serve as good examples.
Writing good unit tests
The idea of a unit test is to test the behavior of a piece of code. This is usually a class and some method of it.
When writing tests, you usually would want to write one test per behavior: Expected behavior of code when given correct values and expected behavior of code when given incorrect values are the essential ones you will want to write. Depending on the case, there may be more tests that you’ll want to write, but these two are good ones to start with.
A common metric for determining how good a set of unit tests are is code coverage. Code coverage is determined by checking how much of the total code your unit tests execute – does each if and else block get executed by some test, does every function get called, etc.
While code coverage is a quite good metric, it can be misleading. Even if your tests cover 100% of your code, they may not actually test each behavior correctly.
I’ll show you some examples of good tests and testing behaviors next week.
In closing
Unit testing is a great way to improve code quality – correctness, but also modularity, because it forces you to write code in a way that it’s reusable and flexible, as it would otherwise be difficult to test.
In the next part we will take a more hands-on coding approach and I’ll show you some practical examples of writing unit tests.