Menu

Bespotten van privé-, statische en ongeldige methoden met behulp van Mockito

  • Hoofd
  • Andere
  • Bespotten van privé-, statische en ongeldige methoden met behulp van Mockito

mocking private static

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Leer bespottende privé-, statische en ongeldige methoden in Mockito met voorbeelden:

In deze serie hands-on Tutorials over Mockito , we hebben de verschillende soorten Mockito Matchers in de laatste tutorial.

Over het algemeen vallen bespotting van privé- en statische methoden onder de categorie van ongebruikelijke bespotting.

Als de behoefte zich voordoet om privé- en statische methoden / klassen te bespotten, duidt dit op slecht geherstructureerde code en is het niet echt een testbare code en is het hoogstwaarschijnlijk dat sommige oude code die niet werd gebruikt, erg unit-testvriendelijk was.

Dat gezegd hebbende, er bestaat nog steeds ondersteuning voor het bespotten van privé- en statische methoden door enkele testkaders voor eenheden zoals PowerMockito (en niet rechtstreeks door Mockito).

Privé, statische en ongeldige methoden van bespotten in Mockito

Spottende 'void' -methoden zijn gebruikelijk omdat er methoden kunnen zijn die in wezen niets retourneren, zoals het bijwerken van een databaserij (beschouw het als een PUT-bewerking van een Rest API-eindpunt dat invoer accepteert en geen uitvoer retourneert).

Mockito biedt volledige ondersteuning voor het bespotten van ongeldige methoden, die we in dit artikel met voorbeelden zullen zien.

functioneel testen en niet-functioneel testen

Wat je leert:

Powermock - Een korte introductie

Voor Mockito is er geen directe ondersteuning om privé- en statische methoden te bespotten. Om privémethoden te testen, moet u refactor de code om de toegang tot beschermd (of pakket) te wijzigen en u zult statische / definitieve methoden moeten vermijden.

Mockito biedt naar mijn mening opzettelijk geen ondersteuning voor dit soort spot, omdat het gebruik van dit soort codeconstructies codegeur en slecht ontworpen code is.

Maar er zijn raamwerken die het bespotten van privé- en statische methoden ondersteunen.

Powermock breidt de mogelijkheden van andere frameworks zoals EasyMock en Mockito uit en biedt de mogelijkheid om statische en privé-methoden te bespotten.

# 1) Hoe: Powermock doet dit met behulp van aangepaste bytecode-manipulatie om bespottende privé- en statische methoden, laatste klassen, constructeurs, enzovoort te ondersteunen.

# 2) Ondersteunde pakketten: Powermock biedt 2 extensie-API's: een voor Mockito en een voor easyMock. Omwille van dit artikel gaan we voorbeelden schrijven met de Mockito-extensie voor power mock.

# 3) Syntaxis ​Powermockito heeft een bijna vergelijkbare syntaxis als Mockito, behalve enkele aanvullende methoden om statische en privémethoden te bespotten.

# 4) Powermockito-installatie

Om de Mockito-bibliotheek op te nemen in gradle-gebaseerde projecten, staan ​​hieronder de bibliotheken die moeten worden opgenomen:

​

Vergelijkbare afhankelijkheden zijn ook beschikbaar voor maven.

Powermock-api-mockito2 - De bibliotheek is vereist om Mockito-extensies voor Powermockito op te nemen.

Powermock-module-junit4 - Module is vereist om PowerMockRunner op te nemen (dit is een aangepaste hardloper die moet worden gebruikt voor het uitvoeren van tests met PowerMockito).

Een belangrijk punt om op te merken is dat PowerMock Junit5-testrunner niet ondersteunt. Daarom moeten de tests worden geschreven tegen Junit4 en moeten de tests worden uitgevoerd met PowerMockRunner.

Om PowerMockRunner te gebruiken, moet de testklasse worden geannoteerd met @RunWith (PowerMockRunner.class)

Laten we nu eens in detail discussiëren over privé, statische en ongeldige methoden!

Spottende privémethoden

Het bespotten van privémethoden, die intern worden aangeroepen vanuit een methode die wordt getest, kan op bepaalde momenten onvermijdelijk zijn. Met powermockito is dit mogelijk en wordt de verificatie uitgevoerd met een nieuwe methode genaamd ‘verifyPrivate’

Laten we nemen eenVoorbeeld waarbij methode onder test een privémethode aanroept (die een boolean retourneert). Om deze methode te stubben om true / false te retourneren, afhankelijk van de test, moet een stub voor deze klasse worden ingesteld.

Voor dit voorbeeld wordt de klasse die wordt getest gemaakt als een spionage-instantie met bespotting op enkele interface-aanroepen en aanroep van een privémethode.

Belangrijke punten voor Mock Private Method:

# 1) De testmethode of testklasse moet worden geannoteerd met @ PrepareForTest (ClassUnderTest). Deze annotatie vertelt powerMockito om bepaalde klassen voor te bereiden om te testen.

Dit zijn meestal de klassen die nodig zijn Bytecode gemanipuleerd ​Typisch voor laatste klassen, klassen die privé- en / of statische methoden bevatten die tijdens het testen moeten worden bespot.

Voorbeeld:

​

#twee) Om stub in te stellen op een privémethode.

Syntaxis ​ when (mock- of spy-instantie, 'privateMethodName'). thenReturn (// retourwaarde)

Voorbeeld:

​

# 3) Om de stubbed private methode te verifiëren.

Syntaxis - verifyPrivate (mockedInstance) .invoke ('privateMethodName')

Voorbeeld:

​

Compleet testvoorbeeld: Voortbordurend op hetzelfde voorbeeld uit de vorige artikelen, waar priceCalculator enkele bespotte afhankelijkheden heeft, zoals itemService, userService enz.

We hebben een nieuwe methode gemaakt genaamd - berekenPriceWithPrivateMethod, die een privémethode binnen dezelfde klasse aanroept en teruggeeft of de klant anoniem is of niet.

​

Spottende statische methoden

Statische methoden kunnen op dezelfde manier worden bespot als we zagen voor de privémethoden.

Wanneer een methode die wordt getest, een statische methode uit dezelfde klasse (of uit een andere klasse) gebruikt, moeten we die klasse opnemen in de annotatie preparForTest vóór de test (of in de testklasse).

Belangrijke punten voor Mock Static Methods:

# 1) De testmethode of testklasse moet worden geannoteerd met @ PrepareForTest (ClassUnderTest). Net als bij het bespotten van privémethoden / klassen, is dit ook vereist voor statische klassen.

#twee) Een extra stap die nodig is voor statische methoden is - mockStatic (// naam van statische klasse)

Voorbeeld:

​

# 3) Om stub op een statische methode in te stellen, is net zo goed als elke methode op een andere interface / klasse mock-instances te stoppen.

Bijvoorbeeld: Om de statische methode GetDiscountCategory () (die een enum DiscountCategory met waarden PREMIUM & GENERAL retourneert) van de klasse DiscountCategoryFinder te stubben, gaat u gewoon als volgt verder:

​

# 4) Om de nep-setup op de laatste / statische methode te verifiëren, kan de methode verifyStatic () worden gebruikt.

Voorbeeld:

​

Mocking Void-methoden

Laten we eerst proberen te begrijpen wat voor soort gebruiksscenario's het mogelijk zijn om methodes om ongeldig te verklaren te voorkomen:

# 1) Methode roept bijvoorbeeld op - die tijdens het proces een e-mailmelding verzendt.

Bijvoorbeeld ​Stel dat u uw wachtwoord voor uw internetbankierrekening wijzigt, zodra de wijziging is geslaagd, ontvangt u een melding via uw e-mail.

Dit kan worden gezien als / changePassword als een POST-aanroep naar de Bank API die een aanroep van een ongeldige methode bevat om een ​​e-mailmelding naar de klant te sturen.

#twee) Een ander veelvoorkomend voorbeeld van de aanroep van de ongeldige methode zijn bijgewerkte verzoeken naar een database die enige invoer vergen en niets teruggeven.

Stubbing ongeldige methoden (d.w.z. de methoden die niets retourneren of anders een uitzondering genereren), kunnen worden afgehandeld met doNothing (), doThrow () en doAnswer (), doCallRealMethod () functies ​Het vereist dat de stub wordt ingesteld met behulp van de bovenstaande methoden volgens de testverwachtingen.

Houd er ook rekening mee dat alle aanroepen van de void-methode standaard worden bespot met doNothing (). Dus zelfs als er geen expliciete nep-setup is gedaan op ONGELDIG method-aanroepen, is het standaardgedrag nog steeds doNothing ().

Laten we eens kijken naar voorbeelden van al deze functies:

Laten we voor alle voorbeelden aannemen dat er een klasse is StudentScoreUpdates die een methode heeft berekenSumAndStore (). Deze methode berekent de som van scores (als invoer) en roept een leegte methode updateScores () op databaseImplementation-instantie.

​

We zullen eenheidstests schrijven voor de aanroep van de nepmethode met de onderstaande voorbeelden:

# 1) doNothing () - doNothing () is het standaardgedrag voor aanroepen van ongeldige methoden in Mockito, d.w.z. zelfs als u een aanroep op void-methode verifieert (zonder expliciet een void in te stellen om doNothing (), zal de verificatie nog steeds succesvol zijn)

​

Andere toepassingen samen met doNothing ()

naar) Wanneer de void-methode meerdere keren wordt aangeroepen en u verschillende reacties wilt instellen voor verschillende aanroepen, zoals - doNothing () voor de eerste aanroep en een uitzondering werpen op de volgende aanroep.

Bijvoorbeeld ​Stel mock als volgt op:

​

b) Als je de argumenten wilt vastleggen waarmee de void-methode werd aangeroepen, moet de ArgumentCaptor-functionaliteit in Mockito worden gebruikt. Dit geeft een extra verificatie van argumenten waarmee de methode werd aangeroepen.

Voorbeeld met ArgumentCaptor:

​

# 2) doThrow ()​ Dit is handig als u gewoon een exception wilt genereren wanneer de void-methode wordt aangeroepen vanuit de methode die wordt getest.

Bijvoorbeeld:

​

# 3) doAnswer ()​ doAnswer () biedt eenvoudigweg een interface om wat aangepaste logica te doen.

Bijv. Een waarde wijzigen door de doorgegeven argumenten, aangepaste waarden / gegevens retourneren die een normale stub niet had kunnen retourneren, vooral voor ongeldige methoden.

Voor demonstratiedoeleinden: ik heb de updateScores () void-methode tegengehouden om een ​​' antwoord() ”En druk de waarde af van een van de argumenten die had moeten worden doorgegeven toen de methode had moeten worden aangeroepen.

Code Voorbeeld:

​

# 4) doCallRealMethod ()​ Gedeeltelijke bespottingen zijn vergelijkbaar met stubs (waar u echte methoden kunt aanroepen voor sommige methoden en de rest kunt uitstoten).

Voor ongeldige methoden biedt mockito een speciale functie genaamd doCallRealMethod () die kan worden gebruikt wanneer u probeert de mockito op te zetten. Wat dit zal doen, is de real void-methode aanroepen met de feitelijke argumenten.

Bijvoorbeeld:

​

tips & trucs

# 1) Meerdere statische klassen opnemen in dezelfde testmethode / klasse- PowerMockito gebruiken als het nodig is om meerdere Static of Final-klassen te bespotten, dan zijn de klassenamen in @ PrepareForTest annotatie kan worden vermeld als een door komma's gescheiden waarde als een array (het accepteert in wezen een array van de klassenamen).

Voorbeeld:

​

Zoals in het bovenstaande voorbeeld wordt getoond, neem aan dat zowel PriceCalculator als DiscountCategoryFinder laatste klassen zijn die bespot moeten worden. Beide kunnen worden genoemd als een reeks klassen in PrepareForTest-annotatie en kunnen in de testmethode worden gestopt.

# 2) Positionering van attribuut PrepareForTest - De positionering van dit attribuut is belangrijk met betrekking tot het soort tests dat in de testklasse is opgenomen.

wat is een .jnlp-bestand

Als alle tests dezelfde laatste klasse moeten gebruiken, is het logisch om dit attribuut op testklasseniveau te vermelden, wat simpelweg betekent dat de voorbereide klasse beschikbaar zal zijn voor alle testmethoden. Als de annotatie daarentegen op de testmethode wordt vermeld, is deze alleen beschikbaar voor die specifieke tests

Gevolgtrekking

In deze tutorial hebben we verschillende benaderingen besproken om statische, definitieve en ongeldige methoden te bespotten.

Hoewel het gebruik van veel statische of definitieve methoden de testbaarheid belemmert, is er toch ondersteuning beschikbaar voor testen / bespotten om te helpen bij het maken van unit-tests om meer vertrouwen in de code / applicatie te krijgen, zelfs voor legacy-code die over het algemeen niet wordt gebruikt om ontworpen zijn voor testbaarheid.

Voor statische en definitieve methoden heeft Mockito geen standaardondersteuning, maar bibliotheken zoals PowerMockito (die veel dingen van Mockito erven) bieden dergelijke ondersteuning en moeten daadwerkelijk bytecode-manipulatie uitvoeren om deze functies te ondersteunen.

Mockito out of the box ondersteunt stubbing void-methoden en biedt verschillende methoden zoals doNothing, doAnswer, doThrow, doCallRealMethod etc. en kan worden gebruikt volgens de vereisten van de test.

De meest gestelde vragen over Mockito-sollicitatiegesprekken worden in onze volgende tutorial besproken.

PREV-zelfstudie ​ VOLGENDE zelfstudie

Aanbevolen literatuur

^