Is wrapping a third party code the only solution to unit test its consumers?

Question

I'm doing unit testing and in one of my classes I need to send a mail from one of the methods, so using constructor injection I inject an instance of Zend_Mail class which is in Zend framework.

Now some people argue that if a library is stable enough and won't change often then there is no need to wrap it. So assuming that Zend_Mail is stable and won't change and it fits my needs entirely, then I won't need a wrapper for it.

Now take a look at my class Logger that depends on Zend_Mail:

class Logger{
 private $mailer; 
 function __construct(Zend_Mail $mail){
 $this->mail=$mail;
 } 
 function toBeTestedFunction(){
 //Some code
 $this->mail->setTo('some value');
 $this->mail->setSubject('some value');
 $this->mail->setBody('some value');
 $this->mail->send();
 //Some
 } 
}

However, Unit testing demands that I test one component at a time, so I need to mock the Zend_Mail class. In addition I'm violating the Dependency Inversion principle as my Logger class now depends on concretion not abstraction.

Now how can I test Logger in isolation without wrapping Zend_Mail?!

The code is in PHP, but answers doesn't have to be. This is more of a design issue than a language specific feature

• kevin cline: Do you have to use an interface? Doesn't PHP support duck typing?
• Songo: @kevincline well I used PHP because it's the language that I use most, but I'm actually looking for a general solution to problem not limited to PHP only.

Answer 1

You always want to wrap third party types and methods behind an interface. This can be tedious and painful. Sometimes you can write a code generator or use a tool to do this.

But don't be tempted to use the library methods or types throughout your code. To begin with, you will have trouble writing unit tests. Then a license will change, or you'll want to go to a platform not supported by the third party, and you will find that those types and dependencies have woven in and around all your other classes.

The ability to change third party vendors quickly is a huge advantage.

• Ben: "Anything not written by you" is a bit much. Libraries that are part of the standard or platform are difficult to wrap. You probably wouldn't want to wrap all of the .NET components, for example. If the wrappers are just pass through interfaces, or are generated code, I have found little benefit to writing tests. If there is logic in there (combining calls, etc.) tests can be helpful.
• Blrfl: Upvoted for the last sentence.
• kevin cline: If you refactor properly, any repetitive use of library facilities will be factored out into a service class. No need to define it up front.
• Michael Borgwardt: -1: Except in cases where the third party library provides a service for which there is a standardized API, this is a huge waste of time andwill only reduce maintainability by having you duplicate code. Also, YAGNI.
• Blrfl: @MichaelBorgwardt: Sure, but in that case, the standard API becomes the wrapper and you can swap libraries easily.