Stub – to przykładowa implementacja pewnego kodu którego zachowanie chcemy przetestować. I gdy nie mamy dostępu do prawdziwej metody która będzie zwracała te dane to sami piszemy taką metodę aby zwracała zestaw przykładowych danych. Innymi słowy Stub to implementacja danych zależności które mogą być wystarczające w małych projektach czy serwisach. Ponieważ stuby są związane z testami jednostkowymi najlepiej jest je tworzyć w paczce gdzie są takie testy.
Przykład wykorzystania Stub’a
Wyobraźmy sobie że potrzebujemy pobrać konta klientów z bazy danych do wysłania wiadomości np. promocyjnych. W aplikacji mamy AccountRepository z metodą do pobrania wszystkich kont. Bez Mocków trzeba by było zrobić cała konfiguracje z bazą danych do której nie mamy dostępu. W naszym przykładzie mamy dostęp tylko do interfejsu AccountRepository. Do właściwej implementacji też nie mamy dostępu ponieważ np. zajmuje się tym inny zespól, albo dane które nas interesują mogą znajdować się w innym module do którego nie mamy dostępu. Zakładamy więc że nie mamy dostępu do metod które implementują dany interfejs. Wyobraźmy sobie że w serwisie mamy metodę która pobiera wszystkie konta i filtruje je w taki sposób że wyszukuje tylko konta prawdziwe(otwarte) co mogłoby wyglądać w taki sposób:
Ponieważ w servisie mam przekazany accountRepository za pomocą konstruktora również musi to zostać odzwierciedlone w testach. Oznacza to tyle że interfejs jest dependencją naszego serwisu.
Aby móc przetestować interfejs tworzymy klasę Stubowa która jest niczym innym jak prawdziwą implementacja interfejsu AccoutRepositor. Klasa ta zwraca przykładowe dane do przetestowana. Proszę spójrz poniżej jak to może wyglądać.