streamalism.org

1. Oversikt

BDD-begrepet ble laget først av Dan North - tilbake i 2006.

BDD oppfordrer til å skrive tester på et naturlig, lesbart språk som fokuserer på oppførselen til applikasjonen.

Den definerer en tydelig strukturert måte å skrive tester på etter tre seksjoner (Arranger, Act, Assert):

• gitt noen forutsetninger (Ordne)
• når en handling skjer (lov)
• deretter verifiser utdataene (Assert)

Mockito-biblioteket leveres med en BDDMockito klasse som introduserer BDD-vennlige APIer. Denne API-en gjør det mulig for oss å ta en mer BDD-vennlig tilnærming til å arrangere testene våre ved hjelp av gitt () og komme med påstander ved hjelp av deretter().

I denne artikkelen skal vi forklare hvordan vi setter opp våre BDD-baserte Mockito-tester. Vi vil også snakke om forskjeller mellom Mockito og BDDMockito APIer, for til slutt å fokusere på BDDMockito API.

2. Oppsett

2.1. Maven avhengigheter

BDD-smaken av Mockito er en del av mockito-kjerne bibliotek, for å komme i gang trenger vi bare å ta med artefakten:

 org.mockito mockito-core 2.21.0 

For den siste versjonen av Mockito, vennligst sjekk Maven Central.

2.2. Import

Testene våre kan bli mer lesbare hvis vi inkluderer følgende statiske import:

importer statisk org.mockito.BDDMockito. *;

Legg merke til det BDDMockito strekker Mockito, så vi vil ikke gå glipp av noen funksjoner som tilbys av den tradisjonelle Mockito API.

3. Mockito vs. BDDMockito

Den tradisjonelle håningen i Mockito utføres ved hjelp av når (obj).deretter*() i Arranger-trinnet.

Senere kan interaksjon med mocken vår valideres ved hjelp av bekrefte() i Assert-trinnet.

BDDMockito gir BDD-aliaser for forskjellige Mockito metoder, slik at vi kan skrive ordne trinnet vårt ved hjelp av gitt (i stedet for når), på samme måte kan vi skrive Assert-trinnet vårt ved hjelp av deretter (i stedet for bekrefte).

La oss se på et eksempel på et testorgan som bruker tradisjonell Mockito:

når (phoneBookRepository.contains (momContactName)) .thenReturn (false); phoneBookService.register (momContactName, momPhoneNumber); verifiser (phoneBookRepository) .insert (momContactName, momPhoneNumber);

La oss se hvordan det sammenlignes med BDDMockito:

gitt (phoneBookRepository.contains (momContactName)) .willReturn (false); phoneBookService.register (momContactName, momPhoneNumber); deretter (phoneBookRepository) .should () .insert (momContactName, momPhoneNumber);

4. Hånende med BDDMockito

La oss prøve å teste PhoneBookService hvor vi må spotte Telefonbok

offentlig klasse PhoneBookService {private PhoneBookRepository phoneBookRepository; public void register (String name, String phone) {if (! name.isEmpty () &&! phone.isEmpty () &&! phoneBookRepository.contains (name)) {phoneBookRepository.insert (name, phone); }} offentlig strengesøk (strengnavn) {if (! name.isEmpty () && phoneBookRepository.contains (name)) {return phoneBookRepository.getPhoneNumberByContactName (name); } returner null; }}

BDDMockito som Mockito tillater oss å returnere en verdi som kan være fast eller dynamisk. Det vil også tillate oss å kaste et unntak:

4.1. Returnerer en fast verdi

Ved hjelp av BDDMockito, Vi kunne enkelt konfigurere Mockito til å returnere et fast resultat når vår metode for mock-objektmål blir påkalt:

gitt (phoneBookRepository.contains (momContactName)) .willReturn (false); phoneBookService.register (xContactName, ""); deretter (phoneBookRepository) .should (never ()) .insert (momContactName, momPhoneNumber);

4.2. Returnerer en dynamisk verdi

BDDMockito lar oss gi en mer sofistikert måte å returnere verdier på. Vi kan returnere et dynamisk resultat basert på innspillene:

gitt (phoneBookRepository.contains (momContactName)) .willReturn (true); gitt (phoneBookRepository.getPhoneNumberByContactName (momContactName)) .will ((InvocationOnMock invocation) -> invocation.getArgument (0) .equals (momContactName)? momPhoneNumber: null); phoneBookService.search (momContactName); deretter (phoneBookRepository) .should () .getPhoneNumberByContactName (momContactName); 

4.3. Kaster et unntak

Å si Mockito om å kaste et unntak er ganske grei:

gitt (phoneBookRepository.contains (xContactName)) .willReturn (false); willThrow (ny RuntimeException ()). gitt (telefonBookRepository) .innsetting (hvilken som helst (String.class), eq (tooLongPhoneNumber)); prøv {phoneBookService.register (xContactName, tooLongPhoneNumber); fail ("Bør kaste unntak"); } catch (RuntimeException ex) {} then (phoneBookRepository) .should (never ()) .insert (momContactName, tooLongPhoneNumber);

Legg merke til hvordan vi byttet stillingene til gitt og vil*, det er obligatorisk i tilfelle vi spotter en metode som ikke har noen returverdi.

Legg også merke til at vi brukte argumentmatchere som (noen, ekv) for å gi en mer generisk måte å spotte basert på kriterier snarere enn avhengig av en fast verdi.

5. Konklusjon

I denne raske opplæringen diskuterte vi hvordan BDDMockito prøver å få en BDD-likhet med våre Mockito-tester, og vi diskuterte noen av forskjellene mellom Mockito og BDDMockito.

Som alltid kan kildekoden bli funnet på GitHub - i testpakken com.baeldung.bddmockito.