Jak przetestowac taka metode ? mockito

Chcialbym przetestowac taka metode z klasy B, uzywajac mockito (nie powermocka ;P)

public void assure() {

    logger.info("1");


    Map<String, String> map = getSTHMap();

    ws = map.get("ws");

    cN = map.get("cN");

    cP = map.get("cP");

    logger.info("2");

 
    Sth s = createCws();

    prepareRequest();
 
    sav();

  }

Moj biezacy test:

@Test

  public void testAssure() {

    doReturn(generatePM()).when(b).getSTHMap();  //generatePM zwraca przygotowana spoecjhalnie mape do testow

    doReturn(null).when(b).createCws();

    doNothing().when(b).prepareRequest();

    

    b.assureFresh();

   

    verify(b, times(1)).getSTHMap();

    verify(b, times(1)).createCws();

    verify(b, times(1)).prepareRequest();

    verify(b, times(1)).sav();

   

    assertEquals("wsTest", b.getws());

    assertEquals("cNTest", b.getcN());

    assertEquals("cPTest", b.getcP());

  }

Metody createCws i prepareRequest musialem zrobic pakietowe (aby byly widoczne), da sie jakos te warunki 'when coś tam' zrobic bez zmieniania dostepu (private) ?
Klase B b zastabowalem uzywajac spy, dlatego, ze testuje metode assure (ktora jest metoda publiczna klasy B) i metoda assure wywoluje w sobie kilka metod prywatnych z klasy B.
Da sie jakos przetestowac podwojne wywolanie loggera?

Co sadzicie o tym tescie ? Czy da sie lepiej przetestowac ta metode nie robiac w niej jakiegos wielkiego refactoringu ?

To jest bez sensu co robisz. Skoro te metody są prywatne to gdzie je niby testujesz? Bo tutaj widzę że chcesz je zamockować, więc ich nie przetestujesz. A skoro są prywatne to też ich nie przetestujesz. Więc kiedy? Pytanie brzmi co ty tu chcesz przetestować właściwie, bo ta metoda generalnie nadaje sie do poprawy, bo ten kawalek z mapą ewidentnie nie pasuje do reszty, bo jest na niższym poziomie abstrakcji.
Jeśli nie chcesz refaktorować to musisz puścić tą metodę tak jak jest napisana, bez żadnych mocków. Przy okazji powycinałeś tą metodę tak że nie bardzo widać co tam w niej robisz w ogóle, bo taka instrukcja Sth s = createCws(); jest bez sensu trochę.

ok, troche przesadzilem z czyszczeniem oryginalnych nazw, bo to 's' chyba szlo jako parametr do kolejnej metody.

Problem taki jest, ze metod prywatnych nie da sie przetestowac za pomoca mockito, a ponadto te dwie metody prywatne (createcws i preparerequest) sa na moje oko nietestowalne jednostkowo. Potrzebny jest serwer apliakcyjny do ich wykonania, czy zewnetrzna integracja itd. (wiec testy integracyjne, gdyby zastapic te mocki rzeczywistymi obiektami zaczynaly by miec sens, ale po kolei, na razie chce dodac junity...)

Wydaje mi sie, ze w takim wypadku, gdy tych prywatnych metod nie da sie przetestowac, to test tej publicznej powinien sprawdzic tylko czy sa one wywolanew i ile razy, co nie ?
Gdyby te metody prywatne byly uzywane jeszcze gdzies, to warto by pomyslec nad zrobieniem serwisu i tam by byly publiczne i moze jakos testowalne...

Pisze glupoty, czy macie jeszcze jakies uwagi, sugestie ?

Piszesz głupoty. Skoro te twoje metody createcws i preparerequest są tak skomplikowane że wymagają serwera aplikacyjnego to ewidentnie powinny być wydzielone do jakiegoś osobnego serwisu a nie upchane jako metody prywatne. Ile ta klasa ma linii? Poniżej 1000? ;]
Jak już je wydzielisz to możesz te zależności mockować.

Taki test o jakim piszesz nie ma absolutnie sensu chyba że przetestujesz też potem powermockiem te metody prywatne. Bo inaczej to właściwie nic nie testujesz. Gorzej nawet, testujesz implementacje a nie zachowanie/kontrakt. Testujesz "czy metoda wygląda tak jak wyglądała kiedy pisałem ten test" a nie to co metoda robi ;]

Zrób tak:

1. Jeśli któraś z tych metod prywatnych woła inne prywatne albo sama jest skomplikowana i wygląda na coś co trzeba by przetestować to wydziel taki zestaw do nowej klasy / nowego serwisu a tą metodę zrób package private albo publiczną
2. Jeśli metoda prywatna jest mała i prosta to zostaw.
3. Napisz test który mockuje tylko te wydzielone zależności z resztę prywatnych metod woła, tak żeby zostały realnie przetestowane.
4. Napisz testy do tych wydzielonych nowych klas.`

no tak, instrukcja ta jest sensowna w wiekszosci przypadkow.

Ale nie widzisz tego kodu, akurat tutaj :P

Te dwie metody prywatne sa bardzo male, maja po dwie linijki.
Moge je wydzielic do jakiegos utila, tutaj mockujac. Ale w tym utilu wcale ich nie przetestuje jednostkowo, tylko co najwyzej integracyjnie (z serwerem, integracjami zewnetrznymi itp.)

Ale niby co takiego one używają czego powermock nie może ogarnąć? Truno mi w taką sytuację uwierzyć. Nie widziałem jeszcze kodu który po sensownym refaktoringu nie nadawał się do przetestowania z użyciem EasyMock+Powermock