jUnit test oraz Mockito

Witam,

Mam pytanie odnośnie Mockito i testów jednostkowych. Nie wiem czy robię coś źle, czy nie rozumiem koncepcji Mockito. Mam o to taką klasę:

public class Point {
    public double getX() {
        return 0d;
    }
}

oraz klasę testującą:

public class PointTest {
    @Test
    public void test() {
        Point p = mock(Point.class);

        when(p.getX()).thenReturn(2.0);

        System.out.println(p.getX());

        verify(p, times(1)).getX();

        assertEquals(2.0, p.getX(), 20);
    }
}

I oczywiście testy przechodzą. Mógłby ktoś w prosty sposób mi to wytłumaczyć bo nie rozumiem czemu testy przechodzą.
Pozdrawiam.

Przede wszystkim nie rozumiesz koncepcji mockowania. Mockowanie służy do podmiany w testach obiektów od których zależy Twój testowany obiekt, nigdy zaś w teście nie powinieneś mockować testowanego obiektu. W momencie gdy mockujesz obiekt Mockito tworzy swoje własne proxy implementujące wskazane interfejsy. Proxy to następnie może zostać wykorzystane do nagrywania pewnych zachowań (Mockito.when) oraz ich weryfikacji (Mockito.verify)

Dlaczego testy przechodzą:
Dokładnie z tego powodu który opisałem powyżej. Wpierw mockujesz obiekt (Mockito.mock) Następnie mówisz mu, że niezależnie od implementacji, w momencie gdy zostanie wywołana metoda getX ma zwrócić 2 (Mockito.when). Ostatnie co robisz, to sprawdzasz czy metoda faktycznie została wywołana (Mockito.verify) co w tym przypadku również jest bez sensu, bo jawnie wywołujesz ją linię powyżej (byw. times(1) jest w Mockito domyślnym parametrem). Na końcu masz asercję, która również przechodzi, dlatego że nie testuje ona Twojej implementacji obiektu Point a jedynie zmockowane proxy Mockito.

Źle dobrałeś przykład dlatego nie rozumiesz do czego służy mockito. Jego zadaniem jest tworzenie "zaślepek" klas z których korzysta testowana klasa.

Przykładowo:

class PointService {
	
	private PointDao dao;

	public PointService(PointDao dao) {
		this.dao = dao;
	}
	
	public Point createNewPoint(double point){
		return dao.save(new Point(point));				
	}
}

interface PointDao{

	Point save(Point point);
}

class Point{
	public Point(double point) {
		
	}
}

Chcemy przetestować nasz PointService, który korzysta z PointDao. W tym celu tworzymy mock tego dao:

PointService sut;
PointDao dao ;

@Before
public void setup(){
    dao = mock(PointDao.class);
    sut = new PointService(dao);
}

// i dalej w teście
@Test
public void shouldCreateNewPoint_callDao(){
   when(dao.save(anyObject())).thenAnswer(a-> (Point)(a.getArguments()[0])); // zwraca argument wywołania
   sut.createNewPoint(2.0);
   verify(dao).save(anyObject());
}

Mockujesz kod dao tak by wywołanie metody save zwracało argument przekazany do niej (prosty przypadek) albo jakiś z góry wiadomy wynik.

Inny przykład (już sam test). Chcesz sprawdzić czy w przypadku gdy zależność wyrzuci błąd to zwrócimy odpowiedni status

when(service.call(argument)).thenThrow(new ServiceException());
// when
Status err = sut.makeMagicThatCallService(argument);
// then
assertThat(err).isNok(); // zakładam, że tu masz własny assert napisany

@airborn

airborn napisał(a):

nigdy zaś w teście nie powinieneś mockować testowanego obiektu

No no no, z tym to bym nie przesadzał. Wbrew pozorom może istnieć potrzeba wykorzystania tzw "częściowych mocków". Tzn tworzysz mock object który ma mockowane pewne wybrane metody. Prosty przykład kiedy ma to zastosowanie:

public void metoda(){
if(warunek()){
  akcja1();
else{
  akcja2();
}

Chcielibyśmy teraz przetestować czy ta metoda ma poprawny przebieg, ale nie testując przy tym działania warunek() ani żadnej akcji(), bo te będą miały swoje własne testy. Nie jest wcale takim głupim pomysłem zrobić partial mocka który mockuje warunek oraz akcje, ustawić sobie w teście żeby warunek zwrócił pewną wartość i oczekiwać że wykona się odpowiednia akcja.

Ta, ok to jest jedyny przypadek który wolałem przemilczeć bo często bywa nadużywany by przetestować źle zaprojektowaną klasę/jednostkę. Zresztą w kontekście Mockito częściej będziesz wówczas chyba korzystać z Mockito.spy niż z Mockito.mock i mockował każdą metodę z wykorzystaniem thenCallRealMethod albo mockować z wykorzystaniem Mockito.CALLS_REAL_METHODS