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.xml
za 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 ReadDatabase
przypisać odwołanie do obiektu do zmiennej zamiast do obiektu typu VirtualDatabase
, należy odziedziczyć klasę VirtualDatabase
z RealDatabase
.
Potem okazuje się, że klasa ma RealDatabase
mnó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.
GO TO FULL VERSION