@Blackhorn: Bo to bez sensu - malowanie trawy na zielono.
Testujesz to co ma klasa robic - jak jakas czesc kodu nie jest pokryta w metodzie prywatnej warto sie zastanowic po co ten kod tam sie znajduje. Tak wiec testuj scenariusze "happy case" oraz te "brzegowe"(nulle, puste listy, puste stringi etc...)
@Blackhorn: to zrób ekstrakcję tego algorytmu do osobnej klasy i napisz do niej test.
Testujesz tylko klasy nieprywatne, bo sprawdzasz czy dana klasa zachowuje się poprawnie, a z zewnątrz nie wywolasz metody prywatnej. Pomyśl o tym jak o interfejsie - metody dostępne z zewnątrz to interfejs, który chcesz sprawdzić. De facto nie interesuje cię logika w środku, interesuje cię czy dla dostarczonych danych otrzymasz poprawny wynik.
@Blackhorn: tu nie chodzi o to czy metoda prywatna, tylko jak nisko chcesz testować. Jak programujesz obiektowo, to ładnie jest pisac kod, w którym klasy są małe, więc z założenia klasa powinna mieć taki prosty interfejs publiczny, że testowanie metod prywatnych jest tylko nadużyciem. Ważne jest też, żeby nie testować wszystkich metod publicznych: powinieneś testować kod, który jest używany przez inne moduły. Niestety klasy w słaby sposób enkapsuluja kod: w
#programowanie
Testujesz to co ma klasa robic - jak jakas czesc kodu nie jest pokryta w metodzie prywatnej warto sie zastanowic po co ten kod tam sie znajduje. Tak wiec testuj scenariusze "happy case" oraz te "brzegowe"(nulle, puste listy, puste stringi etc...)
Zastanawiam sie czy ta klasa nie narusza 'single responsibility principle'
Testujesz tylko klasy nieprywatne, bo sprawdzasz czy dana klasa zachowuje się poprawnie, a z zewnątrz nie wywolasz metody prywatnej. Pomyśl o tym jak o interfejsie - metody dostępne z zewnątrz to interfejs, który chcesz sprawdzić. De facto nie interesuje cię logika w środku, interesuje cię czy dla dostarczonych danych otrzymasz poprawny wynik.