Czesc, jakiej szkoly jestescie zwolennikiem? Wolicie wsztrzykiwac zaleznosci do latwiejszego testowania, czy mockowanie, a moze jeszcze cos innego?
Pozdrawiam
0
3
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...
0
Chodzi mi o to, ze znam opinie, ktore mowia, ze ograniczaja DI do minimum ile sie da i wszystko mockuja.
0
A co ty o tym myślisz? (z własnego doświadczenia). Nie ma co się sugerować opiniami innych, nie sprawdzając tego samemu.
0
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?
2
Myślę że wiem co miał autor tematu na myśli, są tak zwane dwie szkoły testów jednostkowych:
- londyńska, która głosi że należy mockować wszystko, testować również wewnętrzne implementacje i zachowania, gdzie przez unit zwykle jest rozumiana pojedyncza metoda
- detroit, która głosi że mockujemy w ostateczności i staramy się tak pisać kod i testy by mocki nie były potrzebne, staramy się tylko testować publiczne zauważalne efekty działania kodu (stan), gdzie przez unit zwykle jest rozumiany unit of work, na który może nawet składać się kilka klas
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ż :)
0
@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.
0
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.)