What kind of testing are you doing when you're testing? Are you really unit testing when you say you are? Does it matter? Of course, sometimes all that matters is you're testing, but during those other times (say, when you're writing proposals, or trying to satisfy a clear and specific need) whereabouts you're testing, what outcomes you're testing, and why you're bothering, and how you're going about it... when all of these things do matter, then it can help to be more precise in your language.
A few months ago, a client asked me for some help, themselves learning how to test in the future. And so, with many thanks to the Drupal UK IRC channel and the wider network of Twitter for all of their efforts, we crowdsourced some descriptions of different testing strategies and motivations, and came up with a:
It's not a definitive resource, intended to win arguments: but it helps as a mind-clearer, I think. It can help stop you—well, me—from calling everything "unit testing" except when it's obviously "behavioural testing." And then (in my case) getting the reason it's called "behavioural" testing wrong all the same.
Feedback welcome, of course. It would be good if the menagerie could both respect authorities (why different testing strategies were called that in the first place) and also demotic usage (what people actually call things in their day-to-day development.) Unless you're still calling everything "unit testing," obviously. That would make for a short document!
