In the last week I've been thinking a lot about the definition for a Unit Test. It's surprisingly hard to nail it down! We know it has to run fast, and it should test one 'unit.' But what's a unit? Even at last week's group discussion at the Seattle Software Craftsmanship Meetup, nobody had a crisp, universally satisfying definition.
This is my definition for a Unit Test:
You might be thinking "but most of my code couldn't even be a potential target of a Unit Test, then!"
- It runs very fast, a couple milliseconds at most.
- During the test, nothing is exercised outside of the project itself - not other services (like databases), not other computers, not other processes.
- It tests one 'small' thing - usually one function or class. Likely not beyond one file. Third-party dependencies can be included here, but ensure that they don't violate item #2.
- Changes outside that one target of the test should not cause failures.
To that I say: It might be time to refactor. Most of your tests might actually be Integration Tests, and should be runnable separately since they will take longer. But do we have a good definition for an Integration Test? :0)