Testing smart wrappers for 3rd party libraries

Suppose you are required to use an unnecessarily complicated, difficult to mock (perhaps it has concrete classes with no virtual interface), and unreliable third-party library that integrates with some external resource such as a socket or a database. You decide to create "wrapper" interfaces/classes to greatly simplify the usage of this library and to allow developers using the wrapper to continue to write testable code. The wrapper's interface looks nothing like the original interface.

I have a few questions about how to test this wrapper.

1. Should the wrapper be tested without the external resource by developing a method-for-method layer over the bad library that can be mocked?

2. When you test your wrapper classes with the 3rd party library (using the external resources) is this a unit test or an integration test? If the external resource can be embedded in memory during the automated test, is it still an integration test?

3. At what point do we quit mocking and stubbing and say that we have a unit. According to wikipedia "A unit is the smallest testable part of an application." but I am finding this difficult to measure. If speed is a factor in decide whether or not we are testing a unit, how do you decide how slow is too slow for the test to be called a unit test?