Edellisessä luvussa kertasimme, kuinka yksikkötestejä kirjoitetaan. Kuitenkin sovelluksessamme tämä ei aina ole kätevää, koska kontrollerin testaaminen vaatii palvelun testaamista, ja palvelun testaaminen edellyttää tietovaraston testaamista.

Tämä riippuvuuksien ketju herättää kysymyksen: Täytyykö meidän testata kaikki moduulit ja niiden riippuvuudet, vai voimmeko simuloida niiden toimintaa — toisin sanoen, mockata ne?

Mockito: Johdanto

Mockito on suosittu kirjasto Javalle, jota käytetään mock-olioiden luomiseen yksikkötesteissä.

Sen avulla kehittäjät voivat simuloida monimutkaisten ulkoisten riippuvuuksien (kuten tietokantojen, palveluiden tai APIen) toimintaa, jotta voidaan eristää ja testata tietyn komponentin (yleensä luokan tai metodin) logiikkaa ilman, että ollaan vuorovaikutuksessa näiden ulkoisten järjestelmien kanssa.

Tämä tekee yksikkötestauksesta ennustettavampaa ja nopeampaa, koska testauksen aikana ei tarvitse tehdä oikeita ulkoisten resurssien kutsuja.

Mock-oliot Mockito-kirjastossa

Tämän avulla kehittäjät voivat varmistaa, että testattava komponentti (yksikkö) toimii oikein ilman riippuvuutta todellisista riippuvuuksista kuten tietokannoista tai kolmannen osapuolen palveluista.

Luokka voidaan merkitä annotaatiolla @Mock luodakseen sen mock-version. Tätä annotaatiota käytetään usein yhdessä @InjectMocks-annotaation kanssa, jolloin riippuvuudet injektoidaan automaattisesti testattavaan luokkaan.

@Mock 
private MyService myServiceMock;

Tämä mock-olio voidaan sitten injektoida riippuvuudeksi toiseen olioon käyttämällä @InjectMocks annotaatiota. Tämä annotaatio injektoi automaattisesti mock-oliot testattavaan luokkaan.

@InjectMocks
private MyController myController;

Keskeiset menetelmät Mockitossa

Mockito tarjoaa laajan valikoiman menetelmiä mock-olioiden hallintaan, jokainen palvelee tiettyä tarkoitusta testausprosessissa. Alla ovat tärkeimmät menetelmät sekä niiden selitykset.

Kontrollerien testaaminen Mockito-kirjastolla

Kontrollereiden testaaminen sisältää usein palveluiden mokkauksen, joita kontrolleri kutsuu. Tässä yhteydessä Mockito on keskeisessä roolissa auttaen eristämään kontrollerin logiikan palvelukerroksesta.

Videon pika yhteenveto

Kontrollereita testataan käyttämällä MockMvc luokkaa, mutta mitä se tarjoaa ja mitkä ovat sen käytön edut?

@Autowired
private MockMvc mockMvc;

MockMvc-luokan avulla voidaan simuloida erilaisia HTTP-pyyntöjä (GET, POST, PUT jne.), välittää parametreja, otsikoita sekä varmistaa vastaukset, tilakoodit, otsikot ja vastaussisällöt, mikä tekee kontrollerien yksikkötestauksesta huomattavasti helpompaa.

Esimerkiksi voidaan käyttää metodeja kuten perform() pyynnön suorittamiseen, andExpect() odotettujen tulosten varmistamiseen ja content() vastaussisällön tarkistamiseen.

Lisäksi voit ketjuttaa väittämiä tarkistaaksesi HTTP-tilan käyttäen status().isOk(), varmistaa JSON-vastauksen rakenteet jsonPath()-komennolla ja paljon muuta.

Nämä työkalut mahdollistavat kattavan testauksen kontrollerin toiminnasta ilman, että tehdään oikeita HTTP-kutsuja.

Keskeiset annotaatiot

@WebMvcTest(BookController.class) annotaatio on tarkoitettu testaukseen kohdistuen BookController-kontrolleriin, lataamalla vain komponentit, jotka ovat tarpeen tälle täsmälliselle kontrollerille. Se sulkee pois muun Spring-infrastruktuurin, mahdollistaen keskittymisen pelkästään kontrollerin testaamiseen.

@WebMvcTest(BookController.class)
public class BookControllerTest 

Lisäksi @MockBean -annotaatio, joka on lisätty bookService -kenttään, luo palvelusta mock-version, jonka avulla voidaan simuloida sen toimintaa. Tämä auttaa eristämään kontrollerin sen riippuvuuksista ja keskittymään logiikan testaamiseen.

@MockBean
private BookService bookService;

updateBook-metodin testit

Kirjoitimme kaksi testiä updateBook -metodille, jotka kattavat kaikki mahdolliset tapaukset tälle metodille. Ensimmäisessä testissä varmistetaan, että kaikki onnistui ja että entiteetti päivitettiin.

Tämä testi varmistaa book-tietueen onnistuneen päivittämisen, jos se löytyy tietokannasta. Palvelun updateBook() metodia kutsutaan kirjan Id:llä ja bookRequestDTO-oliolla, minkä jälkeen se palauttaa bookResponseDTO-olion, joka edustaa päivitettyä kirjaa.

Poikkeustilanteen tarkistus

Mukana on myös testi, jossa updateBook-metodissa tapahtuu poikkeus, ja tulee varmistaa, miten kontrolleri käyttäytyy kyseisessä tilanteessa.

Tämä testi tarkistaa kontrollerin toiminnan, kun yritetään päivittää kirjaa, jota ei löydy tietokannasta. Palvelun updateBook() metodia kutsutaan ensin kirjan Id:llä ja bookRequestDTO-oliolla.

Sen sijaan, että saataisiin onnistunut tulos, palvelu heittää ApiException-poikkeuksen, mikä osoittaa, että kirjaa annetulla Id:llä ei löytynyt.

Palvelun testaaminen Mockito-kirjastolla

Kun palvelua testataan, on tärkeää eristää se riippuvuuksista kuten repositorioista tai ulkoisista API-rajapinnoista. Mockito mahdollistaa näiden riippuvuuksien mokkaamisen ja niiden toiminnan määrittelyn testeissä.

Videon lyhyt yhteenveto

Aloitetaan menetelmän testaamisella tilanteessa, jossa se päivittää tiedot onnistuneesti, eli Id on kelvollinen. Käytämme luonnollisesti Mockito-kirjastoa mockkaamaan repositoryn toimintaa.

Metodi bookRepository.findById("1") on mockattu palauttamaan olemassa olevan Book-olion repositorysta, ja bookRepository.save(bookWithRepository) on mockattu palauttamaan päivitetyn kirjan muutosten tallentamisen jälkeen.

updateBook() palvelumetodia kutsutaan päivittämään kirja bookRequestDTO:n perusteella, ja se palauttaa BookResponseDTO:n.

assertNotNull(result) varmistaa, että tulos ei ole null, mikä osoittaa onnistuneen päivityksen, kun taas assertEquals() tarkistaa, että päivitetyn kirjan ID, name, author ja price vastaavat odotettuja arvoja.

 assertNotNull(result);
 assertEquals("1", result.getId());
 assertEquals("Updated Name", result.getName());
 assertEquals("Updated Author", result.getAuthor());
 assertEquals("150", result.getPrice());

Lopuksi verify() varmistaa, että repositoryn findById() ja save() on kutsuttu oikeilla parametreilla.

verify(bookRepository).findById("1");
verify(bookRepository).save(bookWithRepository);

Poikkeuksen tarkistaminen palvelussa

Tämä testi varmistaa, että palvelu heittää ApiException-poikkeuksen, jos päivitettävää Book-kirjaa ei löydy tietokannasta.

Aluksi luodaan BookRequestDTO olio, johon asetetaan päivityksen tiedot, ja testikirjan Id, joka ei ole olemassa tietokannassa, asetetaan arvoksi "999". Metodi bookRepository.findById(idTest) mokataan palauttamaan Optional.empty(), mikä osoittaa, että kyseisellä Id:llä ei löydy kirjaa.

when(bookRepository.findById(idTest)).thenReturn(Optional.empty());

Testissä käytetään assertThrows() metodia tarkistamaan, että kun kutsutaan bookService.updateBook(idTest, bookRequestDTO), heitetään ApiException.

Tämän jälkeen assertEquals() metodit varmistavat, että poikkeuksen viesti vastaa odotettua tekstiä ja että virhetilan arvo on HttpStatus.NOT_FOUND.

ApiException apiException = assertThrows(ApiException.class, () -> {
      bookService.updateBook(idTest, bookRequestDTO);
});

assertEquals("Not found book by id: " + idTest, apiException.getMessage());
assertEquals(HttpStatus.NOT_FOUND, apiException.getHttpStatus());

Metodi verify(bookRepository, never()).save(any(Book.class)) varmistaa, että kirjan tallennusmetodia save() ei kutsuttu, koska kirjaa ei löytynyt eikä päivitystä suoritettu.

verify(bookRepository, never()).save(any(Book.class));

Yhteenveto

Mockito on kirjasto, jolla voidaan luoda mokattuja olioita ja simuloida riippuvuuksien toimintaa sekä eristää testattava koodi. Tämä yksinkertaistaa testaamista, tekee siitä nopeampaa, vakaampaa ja riippumatonta ulkoisista resursseista.