Pytanie o testowanie jednostkowe oraz wstrzykiwanie zależności Opcje

[mrWodoo]

Witam, mam dwa pytania gdyż natrafiłem na te pojęcia
- testowanie jednostkowe
- dependency injection

Jak ja to widzę
- testowanie jednostkowe - to po prostu sprawdzenie czy dany fragmentu kodu (klasy) działa, zwraca co należy i czy POTRZEBNE do tego są rzeczy takie jakie SimpleTest/PHPUnit czy mogę po prostu sprawdzać samemu co zwraca metoda np poprzez uzywania var_dumpa, i jak coś się nie zgadza bo zwróciło coś czego nie powinna to wtedy szukam błędu oraz teraz kwestia tworzenia porządnego kodu, który można testować, kod mam tworzyć tak, że można go testować samodzielnie, bez dokładania mu dziesiątek innych obiektów, może jakaś ciekawa stronka, która opisuje to porządnie (po angielsku może być)

- dependency injection - chodzi w tym o to, że żadna klasa nie tworzy sama w sobie nowych obiektów klas, tylko ma je przekazywane przez parametr lub sięgają po obiekty z 'kontenera' zalezności?

np

[PHP] pobierz, plaintext 
$DI = new DI();
$DI->db = new DB( $loginInformation );
 
 
$application = new Application( $DI->db );
lub ewentualnie w konstruktorze klasy Application robię
$this->db = $DI->db; //$DI przekazuję w parametrze lub ew. robię z tego singletona z dostępem do instancji poprzez statyczną metodę getInstance 
[PHP] pobierz, plaintext 

?


Przepraszam za wszystkie głupoty, które tutaj napisałem, ale na tym polega nauka

[Crozin]

1. DIC może tworzyć wiele instancji tego samego serwisu (patrz: scope) przy czym faktycznie, domyślnie żywotność serwisu zdefiniowana jest przez sam kontener.
2. DIC w żaden sposób nie jest praktyką na ominięcie metod statycznych, które notabene są z reguły wysoce niepożądane.
3. Masz rację, w przypadku takiego Mailera będziemy potrzebować zapewne tylko jednej instancji takiej usługi - stąd też takie jest domyślne zachowanie kontenera (patrz pkt. 1).
4. Taka klasa Application to przykład tzw. Service Locator i również jest przykładem złego kodu. Ba!, nieraz nazywana jest wręcz anty-wzorcem. W Wiki jest krótkie podsumowanie wad takiego rozwiązania. Jest to przeciwieństwo DIC-a.
5. Klasa "serce aplikacji" już z definicji wskazuje, że jest to coś złego, taka klasa bóg.