Design pattern name for thin wrapper for unit testing purpose

Question

Assuming I'm using a class from third party library that does not implement an interface, for example:

class ThirdPartyLibClass {
 void DoThis() { ... }
 void DoThat() { ... }
}

I want to create a very thin wrapper around it, directly reflecting class' interface and delegating to the ThirdPartyLibClass. The purpose of this is to stub ThirdPartyLibClass in my unit tests. Example:

interface IThirdPartyLibClass {
 void DoThis();
 void DoThat();
}
class DefaultImplementation : IThirdPartyLibClass {
 private ThirdPartyLibClass realImplementation = new ThirdPartyLibClass ();
 void DoThis() {
 realImplementation.DoThis();
 }
 void DoThat() {
 realImplementation.DoThat();
 } 
}

Is there a name for this pattern? Wrapper or Adapter seem to differ slightly, and I don't intend to ever swap the implementation in production code, so the interface is exactly the same as that of ThirdPartyLibClass. Also, how would I call the DefaultImplementation to make the pattern usage clear to the reader?

Thanks in advance.

• Doc Brown: Wrapper or Adapter is IMHO fine, you might call it a "test wrapper" or "test adapter", if you prefer. The DefaultImplentation just delegates all API calls directly to the lib, I don't know a shorter term to describe this.
• Piotr: @DocBrown Thanks. I don't like "adapter" in this case because the definition says that it is actually changing the interface while, from my research, "wrapper" is in most places defined as a more general (abstract ;) ) term that can be both adapter and decorator. If there's no well known name then I guess I will go with "wrapper" then.

Answer 1

Creating a wrapper interface and having the default implementation just call into a wrapper type is an example of the delegation pattern.

• Piotr: Thanks, yes this seems right. What about the other part of the question, i.e. naming of the wrapper (a suffix) so that the pattern is clearly visible. Since I'm using C# the word delegate already has specific meaning that can be confusing. "Delegator"? ;) "DelegatingWrapper"?
• Piotr: Anyway I think I'm taking this too far. IThirdPartyLibClass and DefaultThirdPartyLibClass or DefaultThirdPartyLibClassWrapper will suffice. I'll accept your answer. Thanks.
• k3b: According to wikipedia the "delegation pattern"-s purpose is to support "composition over inheritance". I prefer @Doc Brown-s "test wrapper"
• David Arno: @k3b and composition is exactly what is being used in the OP's code. "Test wrapper" is an OK name for it, but it is an example of the delegation pattern.
• Doc Brown: No offense, but sometimes I get the impression bored people invent new terms just by taking an existing term and write the word "pattern" after it.

Answer 2

It's a wrapper, that is all. There is no software problem here that is being solved, so there is no design pattern here. The problem being solved is the bureaucratic problem that testable classes should have an interface and should be accessed through an interface, this one doesn't have an interface and cannot be modified, so you write a wrapper. No pattern.

• David Cowden: Exactly.­ ­ ­ ­ ­ ­
• Piotr: The point here is not to test ThirdPartyLibClass but to test something that uses it. Imagine ThirdPartyLibClass coming from a closed-source library and being for example a class operating on a database. In my own code, that uses this class, I don't want to instantiate it in the test (would require a database instance). I think it's quite obvious so unless I misunderstood your answer, I don't see how this is a bureaucratic problem?