Чи упаковка коду стороннього виробника є єдиним рішенням для тестування споживачів?

Я роблю тестування одиниць, і в одному з моїх класів мені потрібно надіслати пошту одним із методів, тому за допомогою конструкторської ін'єкції я ввожу екземпляр Zend_Mailкласу, який знаходиться в рамках Zend.

Зараз деякі люди стверджують, що якщо бібліотека є достатньо стабільною і не змінюватиметься часто, то не потрібно її переробляти. Тож якщо припустити, що Zend_Mailвона стабільна і не зміниться, і цілком відповідає моїм потребам, тоді мені не потрібна обгортка для цього.

А тепер подивіться на мій клас, Loggerякий залежить від 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
   }        
}

Однак тестування Unit вимагає тестування одного компонента за раз, тому мені потрібно знущатися над Zend_Mailкласом. Крім того, я порушую принцип інверсії залежності, оскільки Loggerтепер мій клас залежить від конкременту, а не від абстракції.

Тепер як я можу випробувати Loggerізоляцію без загортання Zend_Mail?!

Код є в PHP, але відповіді не повинні бути. Це скоріше питання дизайну, ніж особливості мови

Ви завжди хочете, щоб за інтерфейсом обгортати сторонні типи та методи. Це може бути нудно і боляче. Іноді можна написати генератор коду або скористатися інструментом для цього.

Але не спокушайтеся використовувати бібліотечні методи або типи у всьому коді. Для початку у вас виникнуть проблеми з написанням одиничних тестів. Тоді ліцензія зміниться, або ви захочете перейти на платформу, не підтримувану третьою стороною, і ви виявите, що ці типи та залежності вплітаються у всі ваші інші класи та навколо них.

Можливість швидко змінювати сторонніх постачальників - величезна перевага.