Defining unit and integration

I've a rough form of this post boiling away at the back of my noggin for a little while but a post on StackOverflow and an old blog post by Roy Osherove has prompted me to finally write it.

While this goes against a previous post on this subject, I think Roy has hit the nail on the head with his definition of "unit test". Integration tests I have an issue with, but mostly as I think the bucket "integration test" is too large.

I see two types of integration tests:

Unigration Tests: Tests written as unit tests, but as a key part of what they do they hits one external resource which is under complete control of the developer. A unigration test is a fast (as it can be), consistent (with early failure with Inconclusive if the external resource does not exist), automated and repeatable test of a functional unit-of-work in the system. For example testing the individual methods in data access layer.
This differs from Roy's "integration test" in that he does not specify functional unit-of-work in the system and he allows for inconsistent tests, where as for a unigration test only allows for three states, Passed, Failed and Resource Unavailable (Inconclusive).

Pure Integration Tests: Is any test which does not fall into the above two definitions. Either as the developer does not have full control over the resource, is testing more than a single functional unit of work or requires multiple external resources.