1.1 Biblioteka Mockito

Dziś zapoznamy się z zaawansowanymi testami. Dokładniej z biblioteką Mockito . Nawet nie myśl o wycofaniu się z tego biznesu.

Po pierwsze, ta biblioteka jest standardem w testach wiosennych . Co jest właściwie standardem w branży programowania Java backend.

Po drugie, będziesz musiał napisać testy dla swojego kodu Springa . Jedynym sposobem na zrozumienie, że napisany przez Ciebie backend działa tak, jak powinien, jest wywołanie metod jego API . A robienie tego z testami jest 10 razy łatwiejsze niż bez nich. Zobaczysz sam.

Możesz dodać bibliotekę Mockito do swojej pom.xmlza pomocą kodu:

<dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-junit-jupiter</artifactId>
    <version>4.2.0</version>
    <scope>test</scope>
</dependency>

Cały kod źródłowy projektu Mockito można znaleźć na GitHub .

1.2 Pozorowane obiekty

Czym więc jest to Mockito i dlaczego jest takie dobre?

W procesie tworzenia i tworzenia testów bardzo często zachodziła potrzeba wrzucenia do kodu jakiegoś „zalążku” zamiast rzeczywistego obiektu.

Na przykład kod współpracujący z bazą danych jest testowany i coś tam zmienia. Dobrze, aby przed każdym testem stan tej bazy był taki sam (inaczej testy będą inne). I chciałbym, aby baza była prostsza, aby szybko cofnąć te stany.

Lub na przykład testujesz kod, który wysyła przydatne SMS-y. A do wysyłek bezpośrednich używa jakiejś płatnej bramki SMS. Fajnie by było wsunąć w to jakąś wirtualną Bramkę do testowania kodu, żeby nie wysyłać setek SMS-ów do niezrozumiałych osób.

Lub Twój kod żąda danych z innych serwerów WWW, które po prostu nie są dostępne na serwerze testowym. Lub piszesz kod do płatności online, który trzeba przetestować 50 razy, a dopiero potem dopuścić do użycia w prawdziwych kanałach finansowych.

Myślę, że rozumiesz... Obiekty wirtualne, czyli tak zwane obiekty pośredniczące, są bardzo przydatną rzeczą.

I tu pojawia się trudność - Java ma typowanie statyczne. Oznacza to, że aby ReadDatabaseprzypisać odwołanie do obiektu do zmiennej zamiast do obiektu typu VirtualDatabase, należy odziedziczyć klasę VirtualDatabasez RealDatabase.

Potem okazuje się, że klasa ma RealDatabasemnóstwo prywatnych metod i zmiennych, które przechowują referencje do innych rzeczywistych obiektów i nie można w ten sposób napisać normalnego kodu pośredniczącego. W teorii jest dobrze, ale w praktyce to ślepy zaułek.

I tu na ratunek przychodzi ( można przeczytaćDynamicProxy szerzej ), który pojawił się jeszcze w Javie 5. Pozwala on na tworzenie wirtualnych obiektów, na które kompilator nie ma żadnych zastrzeżeń.

Takie wirtualne obiekty nazywane są makietami (od słowa makieta - układ). Biblioteka Mockito była w stanie przenieść pracę z tymi makietami na niespotykany dotąd poziom. Stąd, nawiasem mówiąc, nazwa biblioteki.

1.3 Adnotacja @ExtendWith

Biblioteka Mockito świetnie współpracuje z JUnit, można ją nawet uznać za jej rozszerzenie.

Istnieją dwa sposoby włączenia biblioteki Mockito w testach jednostkowych. Pierwszym sposobem jest dodanie specjalnej adnotacji:

@ExtendWith(MockitoExtension.class)
public class MockitoAnnotationTest {
    ...
}

Drugim sposobem jest włączenie jego działania poprzez wywołanie metody openMocks():

public class MockitoAnnotationTest {
    @BeforeEach
    public void init() {
        MockitoAnnotations.openMocks(this);
   }
}

Najczęściej zobaczysz pierwszą opcję, ale czasami warto wiedzieć, że istnieje druga opcja.

Java university