An opinionated definition of a unit test

During the same C# code reviews that triggered last week’s blog post about writing great unit tests, another discussion tends to pop-up, in particularly with new joiners (both experienced and junior):

“What’s the difference between a unit test and an integration test?”

Well, in my opinion (which is heavily influenced by The Art of Unit Testing, a unit test has the following characteristics:

• Fast (as in a couple of milliseconds)
• Runs in-memory
• Has no dependencies on external I/O-bound resources such as networks, configuration files, databases and such
• Can be run an infinite number times without failing
• Can be run in any order with the other tests
• Doesn’t cause any side-effects that might affect other tests or require manual clean-up
• Cover one or more closely related classes

If a unit test does not meet ALL of these characteristics, it’s an integration test.

But what about subcutaneous tests, automated tests that cover everything from just below the user interface layer (which is usually technologically specific) all the way to the database? The goal of such a test is to cover as much as possible without relying on front-end technologies. So the question if it’s a unit test is kind of irrelevant. It’s more useful to discuss whether or not to include them in a CI build of some sort. And that…