Anybody who is practicing TDD or BDD knows that it is important to abstract dependencies. Especially external dependencies you have no control over. But that might not be enough always.
Last year myself and a few co-workers were in a situation where we all needed to take a rather destructive update from a common dependency in several projects. The change was destructive since it involved renaming of a dependent assembly that was also being used by directly by our projects. Let me try to explain that: My project had two dependencies; A and B. However A in turn depended on B and C. The change was to rename B to D. Not a very common case but it highlighted something interesting.
For my co-workers who did not test their code depending on this assembly the update was virtually impossible. It was virtually impossible to make it even compile. Myself I had abstracted the dependency so it was very easy to make it compile but since the component was used by a lot of assemblies I ran into various assembly loading problems.
Turned out there was only one co-worker that actually could take the change. He had not only abstracted the dependency but also put it in a separate assembly so he isolated the dependency too. As you might imagine the change was rolled back and redesigned to not include the assembly renaming, but it made me think.
Just abstracting your third party dependencies is not enough to minimize the risk of the dependency to break you when there is an update. You must also put the abstraction in a separate assembly so it is isolated. Naturally you can do this on demand to save yourself some work...
So remember; abstraction is nothing - isolation is everything!