Robię testy jednostkowe i na jednej z moich klas muszę wysłać wiadomość e-mail z jednej z metod, więc za pomocą wstrzykiwania konstruktora wstrzykuję instancję Zend_Mailklasy, która jest w środowisku Zend.
Teraz niektórzy twierdzą, że jeśli biblioteka jest wystarczająco stabilna i nie zmienia się często, nie trzeba jej owijać. Zakładając, że Zend_Mailjest stabilny i nie ulegnie zmianie i całkowicie odpowiada moim potrzebom, nie będę potrzebował opakowania.
Teraz spójrz na moją klasę, Loggerktóra zależy od 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
}
}
Jednak testy jednostkowe wymagają testowania jednego elementu na raz, więc muszę wyśmiewać Zend_Mailklasę. Ponadto naruszam zasadę odwrócenia zależności, ponieważ moja Loggerklasa zależy teraz od konkrecji, a nie abstrakcji.
Jak mogę teraz testować Loggerw izolacji bez opakowania Zend_Mail?
Kod jest w PHP, ale odpowiedzi nie muszą być. Jest to raczej kwestia projektu niż funkcja specyficzna dla języka
Odpowiedzi:
Zawsze chcesz zawijać typy i metody stron trzecich za interfejsem. Może to być nudne i bolesne. Czasami możesz napisać generator kodu lub użyć do tego narzędzia.
Ale nie ulegaj pokusie używania metod lub typów bibliotecznych w całym kodzie. Na początek będziesz miał problemy z pisaniem testów jednostkowych. Następnie licencja ulegnie zmianie lub będziesz chciał przejść na platformę nieobsługiwaną przez stronę trzecią, a przekonasz się, że te typy i zależności wplątały się we wszystkie pozostałe klasy.
Ogromną zaletą jest możliwość szybkiej zmiany zewnętrznych dostawców.
źródło