[C.....s]

Mogę zmienić metode z private na package-private żeby miec do niej dostęp w testach czy to jest jakiś anti-pattern?
#java #programowanie

[S.....s]

@Cheessys: nie testuje się metod prywatnych - jeśli chcesz ja przetestować, to jest znak, że może warto zastanowić się czy nie powinna być wydzielona do innej klasy

[Myzreal]

@Cheessys: dostosowywanie kodu żeby pasował do testów ogólnie nie jest dobre IMO

[saquas]

@Cheessys: co robi ta metoda?

[C.....s]

@SuppressWarnings: @Myzreal: @saquas:
Chodzi o to że tą metode wywołuje kilka innych i chciałbym w nich sprawdzić tylko verify czy tam jest wywoływana, a do tej prywatnej napisać osobne testy żeby nie pisać tego samego w każdym teście

[dog_meat]

@Cheessys: testuj metody publiczne które używają tej metody

[S.....s]

@Cheessys: testując metodę nie powinno cię obchodzić jak ona to robi - przekazujesz dane, dostajesz wynik i sprawdzasz, a zewnętrzne zależności mockujesz

[saquas]

@Cheessys: tak jak piszą przedmówcy, jeżeli wynik metod publicznych (tylko te powinieneś testować) jest zgodny z oczekiwaniem, to możesz założyć, że metoda prywatna działa. Natomiast jeżeli ta metoda ma jakąś większą logikę to przenieś tę metodę do nowej klasy i testuj osobno.

[Khaz]

@Cheessys: ale purysci Ci się tutaj trafili. Jak masz dobry powód to możesz.

[S.....s]

@Khaz: mi tam daleko do purysty, ale nigdy nie spotkałem się z dobrym powodem testowania prywatnych metod

[colector1337]

@SuppressWarnings: A załóżmy taki case: masz klasę obsługującą FTP-a, i do tego jedną z opcji to przesłanie po SSH-a, dajmy na to też jakaś osobna klasa, i jest metoda prywatna ustawiająca parametry połączenia, i chcesz przetestować tylko poprawność ustawienia parametrów. Wiem że to można by podciągnąć pod "Takiego setowania to nie testuj, jak dobrze trasferuje pliki po wywołaniu metody publicznej to jest ok", ale później przez brak takiego unit testu na

[S.....s]

@colector1337: nie rozumiem co w tym przypadku jest powodem, dla którego trzeba testować prywatną metodę, jeśli te parametry są takie ważne to można to wydzielić do osobnej klasy

[Przegrywek123]

@Cheessys: stestuj metody publiczne korzystające z tejże, a jak dalej będziesz miał wątpliwości to na chwilę zmień na public, stestuj i usuń, nie widzę problemu. Ważne żeby przeszło testy swoich publicznych zależności

[colector1337]

@SuppressWarnings: Można, ale akurat dla tego przypdaku napisaliśmy unit test dla metody prywatnej i ciężko by to nazwać antypatternem. Na 150 testów *IT, które mają po 15 test casów czasem, jak masz na cały scope kilka Unit Testów żeby pokryć np. metodę prywatną. Najwyżej zawsze refactoring można zrobić. Nie trzymałbym się tak mocno takiego clean codu, bo akurat w przypadku testów, lepiej mieć dobrze działające niż wzorcowo napisane

[C.....y]

@SuppressWarnings: Ja miałem jeden, całkiem niedawno. Ze względu na specyfikę testowanej klasy nie miałem gwarancji powtarzalności wyników przy kolejnych wywołaniach testów na publicznym API (w sensie pod spodem w pętli asynchronicznie leciała sobie jedna metoda, na której logice mi zależało - po jednym przejściu - a nie było sensu wystawiać jej na zewnątrz). Wydłubałem ją w teście refleksją i dzięki temu zawsze wołana była tylko raz.

[p.....k]

@Cheessys: Zostaw prywatną a w testach skorzystaj z refleksji.