Sens mockowania ?

No wlasnie, jak to jest.
Gdy pitrzebuje przetestowac kalse, ktora zawiera inna klase - do ktorej nie mam bezposredniego dostepu - to nia mockuje.
ale jaki to ma sens ? np:

Point p = mock(Point.class);  //ok mockuje sobie kalse Point, bo nie mam do niej dostepu (o to chodzi w mockowaniu, co nie ?)
 
        when(p.getX()).thenReturn(2.0); //kiedy wywolam getX na mockowanym obiekcie ma zwrocic 2
        when(p.getY()).thenReturn(3.0);
        doCallRealMethod().when(p).setLocation(anyDouble(), anyDouble()); // ma wywolac callRealMethod() kiedy setlocation z p dostanie 2 double
        when(p.getLocation()).thenCallRealMethod(); //kiedy wywolamy na p get location wywola sie metoda callRealMethod().
 
        p.setLocation(1.0, 5.0); //wywola sie  tez callRealMethod()
        System.out.println("P(" + p.getX() + "," + p.getY() + "), LOCATION: " + p.getLocation()); 
        zwroci 2 i 3 getLocation + wyuwola callRealMethod()
 
        verify(p, never()).distance(any(Point2D.Double.class));
        verify(p, times(1)).getY();  //weryfikacja ok, gdy raz wywolano getY, 
        verify(p, times(1)).getX(); 

jaki sens tych weryfikacji, gdy mockuje sobie obiekt, okreslam jego zachowanie, a na koniec je weryfikuje,
po co mam weryfikoawc zachowanie, ktore dokladnie wczesniej okreslilem ?

Wydaje mi sie, ze okreslasz zachowanie innych klas, ktore uzywasz w testowanej klasie, po to, zeby sprawdzic czy testowana klasa (przy zalozeniu ze wsio poza nią w 100% działa, po to mocki są) dziala. Jezeli nie dziala, to wiesz, ze nie jest to wina innych klas, bo przeciez masz mocki, ktore dają dokladnie to, co powinny dac zastąpione klasy. Czyli wiesz, gdzie szukac bledu w testowanej klasie.

MSZ:
Jak zmockujesz wszystko to to nie będzie miało sensu. Jeśli chcesz przetestować zachowanie się (co implikuje poprawność, ale właśnie chodzi o konkretne zachowanie, a nie tylko poprawność) danego obiektu to mockujesz obiekty z którymi ten obiekt się komunikuje.

@Karolo_Ot to czy masz do danej klasy dostęp czy nie nie ma absolutnie żadnego znaczenia. Chodzi tu o to żebyś testował KONKRETNĄ METODĘ konkretnej klasy, a nie wszystkie inne z którymi się ona komunikuje. Wykonujesz dzieki mockowi test tylko i wyłączenie danej metody, przy założeniu że wszystko inne działa poprawnie. Weryfikacja mocków pozwala jedynie stwierdzić czy sekwencja wywołań metod była taka jakiej sie spodziewałeś.

Shalom to dobrze opisał, ja tylko dodam: a jak chciałbyś testować metodę która odpala jakiś długi proces na bazie danych / systemie plików / czymkolwiek? Albo dla jej poprawnego wykonania musisz ustawić milion różnych rzeczy ( zmienne środowiskowe / odpowiednia struktura folderów itp )?

Dzieki mockom możesz testować tylko i wyłącznie metodę która z danym mockiem współpracuje + sprawdzić, czy wywołania na mocku są takie jak chcialeś.

Od siebie jeszcze dorzucę:

• mock pozwala na weryfikację zachowania testowanej metody w zależności od danych otrzymanych z metody mockowanej.
• mock zapewnia niezależność testów. Nie ma potrzeby konfigurować elementów środowiska np. bazy danych, kolejek MQ, usług. Dzięki temu test jest jednostkowy.
• mock w pewnych przypadkach pozwala na weryfikację kolejności kroków w procesie. Szczególnie jeżeli różne elementy działają asynchronicznie.

// EDIT

Swoją drogą twój kod to przykład jak nie używać mocków...