Hurtig guide til BDDMockito

1. Oversigt

BDD-begrebet blev opfundet først af Dan North - tilbage i 2006.

BDD tilskynder til at skrive prøver på et naturligt, læsbart sprog, der fokuserer på applikationens opførsel.

Den definerer en klart struktureret måde at skrive prøver på efter tre sektioner (Arranger, Act, Assert):

  • givet nogle forudsætninger (Arranger)
  • hvornår der sker en handling (handling)
  • derefter verificer output (Assert)

Mockito-biblioteket leveres med en BDDMockito klasse, der introducerer BDD-venlige API'er. Denne API giver os mulighed for at tage en mere BDD-venlig tilgang til at arrangere vores tests ved hjælp af givet () og fremsætte påstande ved hjælp af derefter().

I denne artikel vil vi forklare, hvordan vi opsætter vores BDD-baserede Mockito-tests. Vi vil også tale om forskelle mellem Mockito og BDDMockito API'er, for til sidst at fokusere på BDDMockito API.

2. Opsætning

2.1. Maven afhængigheder

BDD-smagen af ​​Mockito er en del af mockito-kerne bibliotek, for at komme i gang skal vi bare medtage artefakten:

 org.mockito mockito-core 2.21.0 

For den nyeste version af Mockito, se Maven Central.

2.2. Import

Vores tests kan blive mere læsbare, hvis vi inkluderer følgende statiske import:

importer statisk org.mockito.BDDMockito. *;

Læg mærke til det BDDMockito strækker sig Mockito, så vi går ikke glip af nogen funktion leveret af den traditionelle Mockito API.

3. Mockito vs. BDDMockito

Den traditionelle hån i Mockito udføres ved hjælp af når (obj).derefter*() i Arranger-trin.

Senere kan interaktion med vores mock valideres ved hjælp af verificere() i Assert-trinnet.

BDDMockito giver BDD-aliasser til forskellige Mockito metoder, så vi kan skrive vores Arranger-trin ved hjælp af givet (i stedet for hvornår), ligesom vi kunne skrive vores Assert-trin ved hjælp af derefter (i stedet for verificere).

Lad os se på et eksempel på et testorgan, der bruger traditionel Mockito:

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

Lad os se, hvordan det sammenligner med BDDMockito:

givet (phoneBookRepository.contains (momContactName)) .willReturn (false); phoneBookService.register (momContactName, momPhoneNumber); derefter (phoneBookRepository). skal () .insert (momContactName, momPhoneNumber);

4. Mocking With BDDMockito

Lad os prøve at teste PhoneBookService hvor vi skal spotte TelefonbogOpbevaring:

offentlig klasse PhoneBookService {privat PhoneBookRepository telefonBookRepository; offentligt ugyldigt register (String name, String phone) {if (! name.isEmpty () &&! phone.isEmpty () &&! phoneBookRepository.contains (name)) {phoneBookRepository.insert (name, phone); }} offentlig strengesøgning (strengnavn) {if (! name.isEmpty () && phoneBookRepository.contains (name)) {return phoneBookRepository.getPhoneNumberByContactName (name); } returnere null; }}

BDDMockito som Mockito giver os mulighed for at returnere en værdi, der kan være fast eller dynamisk. Det giver os også mulighed for at kaste en undtagelse:

4.1. Returnering af en fast værdi

Ved brug af BDDMockito, Vi kunne let konfigurere Mockito til at returnere et fast resultat, når vores mock-objekt-målmetode påberåbes:

givet (phoneBookRepository.contains (momContactName)) .willReturn (false); phoneBookService.register (xContactName, ""); derefter (phoneBookRepository). skal (aldrig ()) .insert (momContactName, momPhoneNumber);

4.2. Returnering af en dynamisk værdi

BDDMockito giver os mulighed for at give en mere sofistikeret måde at returnere værdier på. Vi kunne returnere et dynamisk resultat baseret på input:

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

4.3. At kaste en undtagelse

At fortælle Mockito at kaste en undtagelse er ret ligetil:

givet (phoneBookRepository.contains (xContactName)) .willReturn (false); willThrow (ny RuntimeException ()). givet (telefonBookRepository) .indsats (enhver (String.class), eq (tooLongPhoneNumber)); prøv {phoneBookService.register (xContactName, tooLongPhoneNumber); fail ("Bør kaste undtagelse"); } catch (RuntimeException ex) {} then (phoneBookRepository) .should (never ()) .insert (momContactName, tooLongPhoneNumber);

Læg mærke til, hvordan vi udvekslede positionerne for givet og vilje*, det er obligatorisk, hvis vi håner en metode, der ikke har nogen returværdi.

Bemærk også, at vi brugte argumentmatchere som (nogen, ækv) til at give en mere generisk måde at spotte på baseret på kriterier snarere end afhængig af en fast værdi.

5. Konklusion

I denne hurtige vejledning diskuterede vi, hvordan BDDMockito forsøger at bringe en BDD-lighed med vores Mockito-tests, og vi diskuterede nogle af forskellene mellem Mockito og BDDMockito.

Som altid kan kildekoden findes på GitHub - inden for testpakken com.baeldung.bddmockito.


$config[zx-auto] not found$config[zx-overlay] not found