Menu

Mocks en spionnen maken in Mockito met codevoorbeelden

  • Hoofd
  • Andere
  • Mocks en spionnen maken in Mockito met codevoorbeelden

creating mocks spies mockito with code examples

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Mockito Spy and Mocks-zelfstudie:

In deze Mockito Tutorial-serie , onze vorige tutorial gaf ons een Inleiding tot Mockito Framework ​In deze tutorial leren we het concept van Mocks and Spies in Mockito.

Wat zijn schijnvertoningen en spionnen?

Zowel Mocks als Spies zijn de soorten testdubbels, die handig zijn bij het schrijven van unit-tests.

Mocks zijn een volledige vervanging voor afhankelijkheid en kunnen worden geprogrammeerd om de gespecificeerde uitvoer te retourneren wanneer een methode op de mock wordt aangeroepen. Mockito biedt een standaardimplementatie voor alle methoden van een mock.

Het concept van bespotten en spionnen in Mockito

Wat je leert:

Wat zijn spionnen?

Spionnen zijn in wezen een wrapper voor een echt exemplaar van de bespotte afhankelijkheid. Dit betekent dat het een nieuwe instantie van het object of dependency vereist en er vervolgens een wrapper van het bespotte object overheen toevoegt. Standaard roepen spionnen echte methoden van het object aan, tenzij ze worden onderdrukt.

Spionnen bieden wel bepaalde extra bevoegdheden, zoals welke argumenten werden geleverd aan de methodeaanroep, werd de echte methode überhaupt aangeroepen enz.

In een notendop, voor Spies:

  • De echte instantie van het object is vereist.
  • Spionnen geeft flexibiliteit om sommige (of alle) methoden van het bespioneerde object te stoppen. Op dat moment wordt de spion in wezen geroepen of verwezen naar een gedeeltelijk bespot of afgestoten object.
  • De interacties die op een bespioneerd object worden aangeroepen, kunnen voor verificatie worden gevolgd.

In het algemeen worden spionnen niet erg vaak gebruikt, maar ze kunnen nuttig zijn voor het testen van oudere applicaties waarbij de afhankelijkheden niet volledig kunnen worden bespot.

Voor alle beschrijvingen van Mock en Spy verwijzen we naar een fictieve klasse / object genaamd ‘DiscountCalculator’ die we willen bespotten / bespioneren.

Het heeft een aantal methoden zoals hieronder weergegeven:

berekenenKorting - Berekent de kortingsprijs van een bepaald product.
getDiscountLimit - Haalt de bovengrens van de kortingslimiet voor het product.

Mocks creëren

# 1) Mock-creatie met code

Mockito geeft verschillende overbelaste versies van Mockito. Mocks-methode en maakt het mogelijk om schijnwerpers voor afhankelijkheden te maken.

Syntaxis:

​

Voorbeeld:

Stel dat de klassenaam DiscountCalculator is, om een ​​nepcode te maken:

​

Het is belangrijk op te merken dat Mock kan worden gemaakt voor zowel interface als een concrete klasse.

Wanneer een object wordt bespot, retourneren alle methoden standaard null, tenzij ze worden gestopt ​

​

# 2) Mock-creatie met annotaties

In plaats van te spotten met de statische ‘mock'-methode van de Mockito-bibliotheek, biedt het ook een verkorte manier om schijnvertoningen te maken met behulp van‘ @Mock ’-annotatie.

Het grootste voordeel van deze aanpak is dat het eenvoudig is en het mogelijk maakt om aangifte en in wezen initialisatie te combineren. Het maakt de tests ook beter leesbaar en vermijdt herhaalde initialisatie van schijnvertoningen wanneer dezelfde mock op verschillende plaatsen wordt gebruikt.

Om Mock-initialisatie via deze benadering te garanderen, is het vereist dat we ‘MockitoAnnotations.initMocks (this)’ aanroepen voor de klasse die wordt getest. Dit is de ideale kandidaat om deel uit te maken van de ‘beforeEach’ -methode van Junit, die ervoor zorgt dat mock-ups worden geïnitialiseerd telkens wanneer een test wordt uitgevoerd vanuit die klasse.

Syntaxis:

​

Spionnen creëren

Net als Mocks kunnen spionnen ook op 2 manieren worden gemaakt:

# 1) Spionage maken met code

Mockito.spy is de statische methode die wordt gebruikt om een ​​‘spionage’ object / wrapper rond de echte objectinstantie te maken.

Syntaxis:

top 10 spionage-apps voor Android
​

# 2) Spionagecreatie met annotaties

Net als bij Mock kunnen spionnen worden gemaakt met @Spy-annotatie.

Ook voor Spy-initialisatie moet u ervoor zorgen dat MockitoAnnotations.initMocks (dit) wordt aangeroepen voordat de Spy in de eigenlijke test wordt gebruikt om de spion geïnitialiseerd te krijgen.

Syntaxis:

​

Hoe bespotte afhankelijkheden injecteren voor de klasse / het object dat wordt getest?

Als we een nepobject willen maken van de klasse die wordt getest met de andere bespotte afhankelijkheden, kunnen we @InjectMocks-annotatie gebruiken.

Wat dit in wezen doet, is dat alle objecten die zijn gemarkeerd met @Mock (of @Spy) annotaties, worden geïnjecteerd als aannemer of eigendomsinjectie in het klasse-object en vervolgens kunnen interacties worden geverifieerd op het uiteindelijke bespotte object.

Nogmaals, onnodig te vermelden, @InjectMocks is een afkorting tegen het maken van een nieuw object van de klasse en biedt bespotte objecten van de afhankelijkheden.

Laten we dit begrijpen met een voorbeeld:

Stel dat er een klasse PriceCalculator is, die DiscountCalculator en UserService als afhankelijkheden heeft die worden geïnjecteerd via Constructor- of Property-velden.

Dus om de Mocked-implementatie voor de klasse Price calculator te maken, kunnen we 2 benaderingen gebruiken:

# 1) Creëren een nieuw exemplaar van PriceCalculator en injecteer Mocked-afhankelijkheden

​

# 2) Creëren een bespotte instantie van PriceCalculator en injecteer afhankelijkheden via @InjectMocks-annotatie

​

InjectMocks-annotatie probeert eigenlijk bespotte afhankelijkheden te injecteren met behulp van een van de onderstaande benaderingen:

  1. Constructor gebaseerde injectie - Gebruikt Constructor voor de klasse die wordt getest.
  2. Setter Methods Based - Als er geen Constructor is, probeert Mockito te injecteren met property setters.
  3. Veld gebaseerd - Als de bovenstaande 2 niet beschikbaar zijn, probeert het direct via velden te injecteren.

tips & trucs

# 1) Verschillende stubs instellen voor verschillende aanroepen van dezelfde methode:

Wanneer een stubbed-methode meerdere keren wordt aangeroepen binnen de methode die wordt getest (of de stubbed-methode is in de lus en u wilt elke keer een andere uitvoer retourneren), dan kunt u Mock instellen om elke keer een andere stubbed-respons te retourneren.

Bijvoorbeeld: Stel dat je wilt ItemService om een ​​ander item te retourneren voor 3 opeenvolgende oproepen en je hebt items gedeclareerd in je methode onder tests als item1, item2 en item3, dan kun je deze eenvoudig retourneren voor 3 opeenvolgende aanroepen met behulp van de onderstaande code:

​

#twee) Uitzondering gooien via Mock: Dit is een veelvoorkomend scenario wanneer u een downstream / afhankelijkheid wilt testen / verifiëren die een uitzondering genereert en het gedrag van het te testen systeem wilt controleren. Om echter een uitzondering door Mock te genereren, moet u stub instellen met thenThrow.

​

Voor wedstrijden zoals anyInt () en anyString (), raak niet geïntimideerd, want ze zullen in de komende artikelen worden behandeld. Maar in wezen geven ze u gewoon de flexibiliteit om respectievelijk een Integer en String-waarde op te geven zonder specifieke functieargumenten.

Codevoorbeelden - Spionnen en bespotten

Zoals eerder besproken, zijn zowel Spies als Mocks het type testdubbel en hebben ze hun eigen gebruik.

Hoewel spionnen nuttig zijn voor het testen van legacy-applicaties (en waar spot niet mogelijk is), voldoet Mocks voor alle andere mooi geschreven testbare methoden / klassen aan de meeste behoeften van Unit-testen.

Voor hetzelfde voorbeeld: Laten we een test schrijven met Mocks for PriceCalculator -> berekenPrice-methode (de methode berekent itemPrice minus de toepasselijke kortingen)

De PriceCalculator-klasse en de methode die wordt getest calculatiePrijs ziet er als volgt uit:

​

Laten we nu een positieve test voor deze methode schrijven.

We gaan gebruikersservice en itemservice stubben zoals hieronder vermeld:

  1. UserService retourneert altijd CustomerProfile met het loyaltyDiscountPercentage ingesteld op 2.
  2. ItemService retourneert altijd een Artikel met de basisprijs van 100 en van toepassing zijnde korting van 5.
  3. Met de bovenstaande waarden komt de verwachte prijs die wordt geretourneerd door de te testen methode uit op 93 $.

Hier is de code voor test:

​

Zoals u kunt zien, beweren we in de bovenstaande test dat de werkelijke prijs die door de methode wordt geretourneerd, gelijk is aan de verwachte prijs, d.w.z. 93,00.

Laten we nu een test schrijven met Spy.

We bespioneren de ItemService en coderen de ItemService-implementatie op een manier dat deze altijd een item retourneert met de basisprijs 200 en toepasselijke korting van 10,00% (de rest van de mock-setup blijft hetzelfde) wanneer deze wordt aangeroepen met skuCode van 2367.

​

Laten we nu eens kijken naar een Voorbeeld van een uitzondering die wordt gegenereerd door ItemService omdat de beschikbare hoeveelheid van het item 0 was. We zullen een mock opzetten om een ​​uitzondering te genereren.

​

Met de bovenstaande voorbeelden heb ik geprobeerd het concept van Mocks & Spies uit te leggen en hoe ze kunnen worden gecombineerd om effectieve en nuttige Unit-tests te maken.

interviewvragen over rest webservices java

Er kunnen meerdere combinaties van deze technieken zijn om een ​​reeks tests te krijgen die de dekking van de te testen methode vergroten, waardoor een groot vertrouwen in de code wordt gegarandeerd en de code beter bestand is tegen regressiebugs.

Broncode

Interfaces

KortingCalculator

​

ItemService

​

Gebruikersservice

​

Interface-implementaties

DiscountCalculatorImpl

​

ItemServiceImpl

​

Modellen

Klantenprofiel

​

ItemSku

​

Klasse wordt getest - PriceCalculator

​

Eenheidstests - PriceCalculatorUnitTests

​

Verschillende soorten Matchers die door Mockito worden geleverd, worden uitgelegd in onze aanstaande tutorial.

PREV-zelfstudie ​ VOLGENDE zelfstudie

Aanbevolen literatuur

^