Beknopte handleiding voor BDDMockito

1. Overzicht

De BDD-term werd voor het eerst bedacht door Dan North - in 2006.

BDD moedigt het schrijven van tests aan in een natuurlijke, voor mensen leesbare taal die gericht is op het gedrag van de applicatie.

Het definieert een duidelijk gestructureerde manier om tests te schrijven volgens drie secties (Arrange, Act, Assert):

  • gegeven enkele randvoorwaarden (regelen)
  • wanneer er vindt een actie plaats (Act)
  • dan controleer de uitvoer (beweren)

De Mockito-bibliotheek wordt geleverd met een BDDMockito klasse die BDD-vriendelijke API's introduceert. Met deze API kunnen we een meer BDD-vriendelijke benadering volgen door onze tests te organiseren met gegeven() en beweringen doen met dan().

In dit artikel gaan we uitleggen hoe u onze op BDD gebaseerde Mockito-tests instelt. We zullen ook praten over verschillen tussen Mockito en BDDMockito API's, om uiteindelijk te focussen op de BDDMockito API.

2. Installatie

2.1. Afhankelijkheden van Maven

De BDD-smaak van Mockito maakt deel uit van de mockito-core bibliotheek, om aan de slag te gaan, hoeven we alleen het artefact op te nemen:

 org.mockito mockito-core 2.21.0 

Raadpleeg Maven Central voor de nieuwste versie van Mockito.

2.2. Invoer

Onze tests kunnen beter leesbaar worden als we de volgende statische import opnemen:

importeer statische org.mockito.BDDMockito. *;

Let erop dat BDDMockito strekt zich uit Mockito, dus we zullen geen enkele functie van de traditionele Mockito API.

3. Mockito versus BDDMockito

De traditionele spot in Mockito wordt uitgevoerd met wanneer (obj).dan*() in de schikken stap.

Later kan de interactie met onze mock worden gevalideerd met verifiëren() in de Assert-stap.

BDDMockito biedt BDD-aliassen voor verschillende Mockito methoden, zodat we onze stap Schikken kunnen schrijven met gegeven (in plaats van wanneer), zouden we ook onze Assert-stap kunnen schrijven met dan (in plaats van verifiëren).

Laten we eens kijken naar een voorbeeld van een testlichaam met traditionele Mockito:

when (phoneBookRepository.contains (momContactName)) .thenReturn (false); phoneBookService.register (momContactName, momPhoneNumber); verifieer (phoneBookRepository) .insert (momContactName, momPhoneNumber);

Laten we eens kijken hoe dat zich verhoudt BDDMockito:

gegeven (phoneBookRepository.contains (momContactName)) .willReturn (false); phoneBookService.register (momContactName, momPhoneNumber); dan (phoneBookRepository) .should () .insert (momContactName, momPhoneNumber);

4. Bespotten met BDDMockito

Laten we proberen het PhoneBookService waar we de Telefoonboek Opslagplaats:

openbare klasse PhoneBookService {privé PhoneBookRepository phoneBookRepository; openbaar ongeldig register (String-naam, String-telefoon) {if (! name.isEmpty () &&! phone.isEmpty () &&! phoneBookRepository.contains (naam)) {phoneBookRepository.insert (naam, telefoon); }} openbaar String zoeken (String naam) {if (! name.isEmpty () && phoneBookRepository.contains (naam)) {return phoneBookRepository.getPhoneNumberByContactName (naam); } retourneer null; }}

BDDMockito net zo Mockito stelt ons in staat om een ​​waarde te retourneren die vast of dynamisch kan zijn. Het zou ons ook toestaan ​​om een ​​uitzondering te maken:

4.1. Een vaste waarde retourneren

Gebruik makend van BDDMockito, we zouden Mockito gemakkelijk kunnen configureren om een ​​vast resultaat te retourneren wanneer onze mock object target-methode wordt aangeroepen:

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

4.2. Een dynamische waarde retourneren

BDDMockito stelt ons in staat om een ​​meer geavanceerde manier te bieden om waarden te retourneren. We zouden een dynamisch resultaat kunnen retourneren op basis van de invoer:

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

4.3. Een uitzondering werpen

Mockito vertellen om een ​​uitzondering te maken, is vrij eenvoudig:

gegeven (phoneBookRepository.contains (xContactName)) .willReturn (false); willThrow (new RuntimeException ()) .given (phoneBookRepository) .insert (any (String.class), eq (tooLongPhoneNumber)); probeer {phoneBookService.register (xContactName, tooLongPhoneNumber); fail ("zou een uitzondering moeten genereren"); } catch (RuntimeException ex) {} dan (phoneBookRepository) .should (never ()) .insert (momContactName, tooLongPhoneNumber);

Merk op hoe we de posities van hebben uitgewisseld gegeven en zullen*, dat is verplicht voor het geval we een methode bespotten die geen retourwaarde heeft.

Merk ook op dat we argument matchers hebben gebruikt zoals (ieder, eq) om een ​​meer generieke manier van bespotten te bieden op basis van criteria in plaats van afhankelijk van een vaste waarde.

5. Conclusie

In deze korte tutorial hebben we besproken hoe BDDMockito een BDD-gelijkenis probeert te brengen met onze Mockito-tests, en we hebben enkele van de verschillen besproken tussen Mockito en BDDMockito.

Zoals altijd is de broncode te vinden op GitHub - in het testpakket com.baeldung.bddmockito.


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