Great summary of test name confusion by Michael Feathers.
You can name tests after their scope: (unit, component, system), their place in the development process (smoke, integration, acceptance, regression), their focus (performance, functional) their visibility (white box, black box), the role of the people writing them (developer, customer)... The list goes on. There are far more than I can remember.
Why is it so confusing? ... The thing which makes testing nomenclature [bad] is that the tests themselves aren't all that different ... we can tell the difference between a unit test and an acceptance test in most systems, but really there is no force which prevents tests of different types from bleeding through into each other.
I frequently have integration type tests mixed into my unit tests, and only after they've gained enough weight to drag out the execution time of my suite will I start to segregate them. My usual distinguishing factor is ‘quick’ and ‘long-running’.
One of the reasons for this is I tend to favor writing tests which roundtrip to a database (for example) instead of using mocks. I'm fine with mocks (though not so much mock libraries - see DiyMocks), but if using mocks leaves a gap in integration tests, then I'd rather start with the integration test and back fill with mocked unit testing if the testing in that arena becomes intense. However, I've found with proper separation of concerns, the places where mocks would be the most useful tend not to accumulate enough logic to make it worthwhile.
Dale Emery also has an excellent article on this.
Michael Hill weighs in on Microtests vs. Unit Tests. Since he linked to his own post on the testdrivendevelopment yahoo group and I didn't see his definition of unit test in his post, I asked him about it:
The biggest single difference is scope, and the second biggest is shipping-reality.
Traditionally, unit tests involve much larger units. A typical old-school example would be a set of unit tests that run against a COM object, regardless of whether that interface involves a single class or 300 of them. Microtests are truly micro, irrespective of packaging.
Traditionally, unit tests -- indeed most tests -- pay very close attention to testing the exact binary image in the exact binary environment in which it runs. Microtests are almost entirely unconcerned with this. Microtests take for granted that they only test that object X works the way it's supposed to *with the assumption* that object X's collaborators work the way they're supposed to.
So you see that although a unit test *could* be a microtest, the word itself has a prior meaning that confuses experienced test-makers who are XP noobs.
tags: ComputersAndTechnology
