Czesc, jakiej szkoly jestescie zwolennikiem? Wolicie wsztrzykiwac zaleznosci do latwiejszego testowania, czy mockowanie, a moze jeszcze cos innego?
Pozdrawiam
Czesc, jakiej szkoly jestescie zwolennikiem? Wolicie wsztrzykiwac zaleznosci do latwiejszego testowania, czy mockowanie, a moze jeszcze cos innego?
Pozdrawiam
Nie bardzo rozumiem pytanie, bo przecież to są kwestie zupełnie ortogonalne a nie wymienne. Ba, mockowanie doskonale komponuje się z DI, po prostu możesz wstrzykiwać mocki...
Chodzi mi o to, ze znam opinie, ktore mowia, ze ograniczaja DI do minimum ile sie da i wszystko mockuja.
A co ty o tym myślisz? (z własnego doświadczenia). Nie ma co się sugerować opiniami innych, nie sprawdzając tego samemu.
Mam wrażenie że ty po prostu nierozumiesz tych opinii i interpretujesz je błędnie. Moze ktoś np. ogranicza używanie kontenerów IoC a nie DI jako takiego?
Myślę że wiem co miał autor tematu na myśli, są tak zwane dwie szkoły testów jednostkowych:
DI oczywiście tutaj nie ma nic do rzeczy bo występuje w obu tak samo, więc kwestią sporną jest jak bardzo używać mocków, bo tu są dwie odmienne szkoły :)
Kent Beck należy do obozu detroit, ja też :)
@neves:
Tutaj podejście zależy mocno od tego co się pisze. Jeśli piszesz aplikację biznesową to faktycznie podejście "testujemy unit of work" się sprawdza. Ale jeśli testujesz coś co ma działać w różnych warunkach - np. twoja klasa korzysta z interfejsu który może mieć wiele implementacji (w tym ktoś inny sobie może napisać swoją) to mockujesz i piszesz testy pojedynczych metod.
Swoją drogą to ciekawa kwestia że dobre praktyki zależą mocno od kontekstu.
Mockowanie wszystkiego jak leci to świetny sposób na to, by mieć 100% pokrycia kodu testami, które są zawsze zielone - nawet jeśli kod produkcyjny już dawno został rozpieprzony. (No dobra - prawie zawsze zielone. Jak coś się posypie to jedna klasa z testami, a biblioteka mockująca sama podpowie co trzeba zmienić - dziwne, że same jeszcze nie zmieniają kodu z automatu.)