different types matchers provided mockito
oorzakenanalyse voorbeelden softwareontwikkeling
Een inleiding tot verschillende soorten Matchers in Mockito.
Spotten en spionnen in Mockito werden in detail uitgelegd in onze vorige tutorial van gedetailleerd Mockito-trainingsserie
Wat zijn Matchers?
Matchers zijn als regex of jokertekens waarbij u in plaats van een specifieke invoer (en / of uitvoer) een bereik / type invoer / uitvoer specificeert op basis van welke stubs / spionnen rust kunnen zijn en oproepen naar stubs kunnen worden geverifieerd.
Alle Mockito-matchers maken deel uit van ‘ Mockito ' statische klasse.
Matchers zijn een krachtig hulpmiddel, dat een verkorte manier mogelijk maakt om stubs in te stellen en om aanroepen op de stubs te verifiëren door argumentinvoer te noemen als generieke typen voor specifieke waarden, afhankelijk van het gebruik of het scenario.
Wat je leert:
Soorten Matchers in Mockito
Er zijn grofweg 2 soorten matchers in Mockito of qua gebruik kunnen matchers worden gebruikt voor de onderstaande 2 categorieën:
- Argument Matchers tijdens het instellen van de Stub
- Verification Matchers voor het verifiëren van daadwerkelijke aanroepen naar stubs
Voor beide typen matchers, d.w.z. argument en verificatie, biedt Mockito een enorme reeks matchers (klik hier voor een volledige lijst van de matchers).
Argument Matchers
Hieronder staan de meest gebruikte:
Laten we voor al het onderstaande overwegen om een IntegerList te testen:
# 1) any () - Accepteert elk object (inclusief null).
#twee) elke (Java-taalklasse) -
Voorbeeld : any (ClassUnderTest.class) - Dit is een meer specifieke variant van any () en accepteert alleen objecten van het klassetype dat wordt vermeld als de sjabloonparameter.
# 3) anyBoolean (), anyByte (), anyInt (), anyString (), anyDouble (), anyFloat (), anyList () en nog veel meer - Al deze accepteren elk object van het overeenkomstige gegevenstype en ook null-waarden.
# 4) Specifieke argumenten - In gevallen waarin de werkelijke argumenten van tevoren bekend zijn, is het altijd aan te raden om ze te gebruiken, omdat ze meer vertrouwen bieden in vergelijking met generieke argumenttypen.
Voorbeeld:
Verificatie Matchers
Er zijn enkele gespecialiseerde matchers die beschikbaar zijn om dingen als nee te verwachten / beweren. van aanroepingen op de mock.
Laten we voor alle onderstaande matchers dezelfde lijst met voorbeelden bekijken die we eerder hebben gebruikt.
# 1) Mock-aanroepingen
(ik) Een eenvoudige aanroep op Mock verifieert of de bespotte methode al dan niet werd aangeroepen / gebruikt door de grootte van de bespotte lijst in te stellen op 5.
(ii) Een specifiek aantal interacties met een bespotte methode verifieert het aantal nee. vaak werd verwacht dat de mock werd genoemd.
Om 0 interacties te verifiëren, wijzigt u eenvoudig de waarde van 1 in 0 als argument voor times () matcher.
In het geval van fouten, retourneert het de volgende uitzonderingen:
naar) Als de verwachte aanroepen kleiner zijn dan de daadwerkelijke aanroepen:
Voorbeeld: 2 keer gezocht, maar 3 keer aangeroepen, dan keert Mockito terug - ' verificatie.TooManyActualInvocations
Voorbeeld code:
b) Als de verwachte aanroepen meer zijn dan de daadwerkelijke aanroepen:
Voorbeeld: 2 keer gezocht, maar 1 keer aangeroepen, dan keert Mockito terug - ' verificatie.TooLittleActualInvocations
(iii) Geen interacties met de specifieke methode van het bespotte object.
(iv) Controleer de volgorde van de bespotte interacties - Dit is vooral handig wanneer u de volgorde wilt controleren waarin de methoden op de bespotte objecten werden aangeroepen.
Voorbeeld: Database-achtige bewerkingen waarbij een test de volgorde moet verifiëren waarin de database-updates hebben plaatsgevonden.
Om dit aan de hand van een voorbeeld te illustreren - Laten we doorgaan met dezelfde lijst met voorbeelden.
Laten we nu aannemen dat de volgorde van aanroepen naar lijstmethoden in de juiste volgorde was, d.w.z. get (5), size (), get (2). De volgorde van verificatie moet dus ook hetzelfde zijn.
In het geval van een verkeerde verificatievolgorde, wordt er een uitzondering gegenereerd door Mockito - dat wil zeggen ' verificatie.VerificationInOrderFailure
Dus in het bovenstaande voorbeeld, als ik de volgorde van verificatie verander door de laatste twee regels om te wisselen, krijg ik de uitzondering VerificationInOrderFailure.
(v) Controleer of de interactie minstens / hoogstens aantal keren heeft plaatsgevonden.
(naar) tenminste:
Voorbeeld: atleast (3) - Verifieert dat het bespotte object tijdens de test ten minste driemaal is aangeroepen / interactie heeft gehad. Dus elk van de interacties 3 of groter dan 3 zou de verificatie succesvol moeten maken.
In het geval van fouten, d.w.z. wanneer de daadwerkelijke aanroepen niet overeenkomen, wordt dezelfde uitzondering gegenereerd als bij de times () matcher, d.w.z. “ verificatie.TooLittleActualInvocations '
(b) hoogstens:
Voorbeeld: atmost (3) - verifieert of het bespotte object tijdens de test ten minste driemaal is aangeroepen / interactie heeft gehad. Dus elk van de 0,1,2 of 3 interacties met de mock zou de verificatie succesvol moeten maken.
hoe u een .eps-bestand opent
# 2) Het matchen van argumenten
In de bovenstaande aanroep kunnen matchers worden gecombineerd met de argument matchers om de argumenten te valideren waarmee de mock werd aangeroepen.
- ieder()
- Specifieke waarden - Verifieer met de specifieke waarden wanneer de argumenten van tevoren bekend zijn.
- Andere matchende argumenten zoals - anyInt (), anyString () etc.
tips & trucs
# 1) Argument Capture gebruiken tijdens verificatie
Verificatie van Argument Capture is meestal handig als het argument dat door een stubbed methode wordt gebruikt, niet rechtstreeks wordt doorgegeven via een methodeaanroep, maar intern wordt gemaakt wanneer de methode die wordt getest, wordt aangeroepen.
Dit is vooral handig als uw methode afhankelijk is van een of meer medewerkers wiens gedrag is afgeslagen. De argumenten die aan deze medewerkers worden doorgegeven, zijn een intern object of een geheel nieuwe set argumenten.
Het valideren van het feitelijke argument waarmee de medewerkers zouden zijn gebeld, zorgt voor veel vertrouwen in de code die wordt getest.
Mockito biedt ArgumentCaptor die kan worden gebruikt met verificatie en wanneer 'AgumentCaptor.getValue ()' wordt aangeroepen, kunnen we het feitelijk vastgelegde argument tegen het verwachte argument plaatsen.
Raadpleeg het onderstaande voorbeeld om dit te illustreren:
In de onderstaande methode is berekenPrijs het model waarbij de klasse InventoryModel wordt gemaakt in de hoofdtekst van de methode die vervolgens door InventoryService wordt gebruikt voor updates.
Als u nu een test wilt schrijven om te valideren met welk argument de inventoryService is aangeroepen, kunt u eenvoudig het ArgumentCaptor-object van het type InventoryModel class gebruiken.
Methode die wordt getest:
Testcode: Kijk naar de verificatiestap waar inventoryService wordt geverifieerd, het argumentCaptor-object wordt vervangen waarvoor het argument moet worden gevonden.
Bevestig vervolgens eenvoudig de waarde door de methode getValue () aan te roepen op het ArgumentCaptor-object.
Voorbeeld: ArgumentCaptorObject.getValue ()
open een apk-bestand in Windows
Zonder ArgumentCaptor zou er geen manier zijn om vast te stellen met welk argument de serviceaanroep was gemaakt. Het beste is om 'any ()' of 'any (InventoryModel.class)' te gebruiken om argumenten te verifiëren.
# 2) Veelvoorkomende uitzonderingen / fouten bij het gebruik van Matchers
Bij het gebruik van Matchers zijn er bepaalde conventies die moeten worden gevolgd, die, als ze niet worden gevolgd, resulteren in het genereren van een uitzondering. De meest voorkomende die ik tegenkwam, is tijdens het stoten en verifiëren.
Als u argumentMatchers gebruikt en als de stubbed-methode meer dan één argument (en) heeft, dan moeten alle argumenten worden vermeld met matchers, anders mag geen van hen matchers hebben. Nu, wat betekent dit?
Laten we dit proberen te begrijpen met een scenario (en vervolgens een codevoorbeeld voor dit scenario)
- Stel dat de te testen methode een handtekening heeft zoals -
concatenateString (String arg1, String arg2) - Bij het stubben - stel dat je de waarde van arg1 kent, maar arg2 is onbekend, dus je besluit om een argument matcher te gebruiken zoals - any () of anyString () en een waarde voor het eerste argument op te geven, zoals een tekst 'hallo'.
- Wanneer de bovenstaande stap is geïmplementeerd en de test wordt uitgevoerd, genereert de test een uitzondering met de naam 'InvalidUseOfMatchersException'
Laten we dit proberen te begrijpen met een voorbeeld:
Testcode:
Klasse onder test:
Wanneer de bovenstaande test is uitgevoerd, keert deze terug in ' InvalidUseOfMatchersException
Wat is nu de reden voor deze uitzondering?
Het is het stubben met behulp van part matchers en part fixed string, d.w.z. we hebben één argument matcher genoemd als 'hallo' en ten tweede als anyString (). Nu zijn er 2 manieren om van dit soort uitzonderingen af te komen (let ook op: dit gedrag geldt zowel voor Mock-opstellingen als voor gedrag).
# 1) Gebruik Argument Matchers voor alle argumenten:
# 2) Gebruik eq () als de Argument Matcher waar het argument bekend is. Dus in plaats van het argument te specificeren als 'hallo', specificeer je het als 'eq (' hallo ') en dit zou het stubbing succesvol moeten maken.
Gevolgtrekking
In dit artikel hebben we gezien hoe we verschillende soorten matchers van Mockito kunnen gebruiken.
Hier hebben we de meest gebruikte besproken. Om naar de volledige lijst te verwijzen, is de documentatie van de Mockito Library een goede referentiebron.
Bekijk onze aanstaande tutorial om meer te weten te komen over privé-, statische en ongeldige methoden van bespotten.
PREV-zelfstudie VOLGENDE zelfstudie
Aanbevolen literatuur
- Mocks en spionnen maken in Mockito met codevoorbeelden
- Mockito-zelfstudie: Mockito-raamwerk voor bespotten bij het testen van eenheden
- Soorten risico's in softwareprojecten
- Python-gegevenstypen
- C ++ gegevenstypen
- Top 12 Mockito-interviewvragen (Mocking Framework-interview)
- Bespotten van privé-, statische en ongeldige methoden met behulp van Mockito
- Soorten overerving in C ++