mockito tutorial mockito framework
Een complete gids voor Mockito Framework: hands-on Mockito-zelfstudies
regex_match c ++
Unit-testing is een eenvoudige maar effectieve techniek om een goed niveau van vertrouwen te krijgen in de code die moet worden verzonden.
Bovendien vermijdt het regressieproblemen bij elk stukje code dat wordt ingecheckt.
Met een architectuur van het type microservices (en zelfs voor een eenvoudige structuur met elementaire databaseaanroepen), volstaat het niet om een eenheid te testen. Wat we nodig hebben, is de afhankelijkheden bespotten en de werkelijke logica van de te testen methode testen.
Lijst met ALLE Mockito-tutorials in deze serie:
Tutorial # 1: Mockito Framework voor bespotten bij het testen van eenheden (Deze tutorial)
Tutorial # 2: Mocks en spionnen maken in Mockito
Tutorial # 3: Verschillende soorten Matchers aangeboden door Mockito
Tutorial # 4: Bespotten van privé-, statische en ongeldige methoden met behulp van Mockito
Tutorial # 5: Top 12 Mockito-interviewvragen
Overzicht van tutorials in deze Mockito-serie
| Tutorial # | Wat je gaat leren |
|---|---|
| Tutorial # 1: | Mockito Framework voor bespotten bij het testen van eenheden Leer bespotten met Mockito - Een uitgebreide Mockito-zelfstudie voor beginners met codevoorbeelden. Leer bespottelijk kader voor bespotten in unit-testen. |
| Tutorial # 2: | Mocks en spionnen maken in Mockito Mocks en Spies zijn soorten testdubbels, die handig zijn bij het schrijven van unit-tests. Beide worden uitgelegd in deze Mockito Spy-tutorial met codevoorbeelden. |
| Tutorial # 3: | Verschillende soorten Matchers aangeboden door Mockito Leer hoe u verschillende soorten matchers van Mockito kunt gebruiken. Matchers zijn als jokertekens waarbij u in plaats van een specifieke invoer / uitvoer een invoerbereik specificeert. Argument en verificatie zijn de twee soorten Matchers in Mockito die hier in detail worden uitgelegd. |
| Tutorial # 4: | Bespotten van privé-, statische en ongeldige methoden met behulp van Mockito Leer bespottende privé-, statische en ongeldige methoden in Mockito met voorbeelden. Leer het bespotten van privé- en statische methoden door het unit testing framework PowerMockito. |
| Tutorial # 5: | Top 12 Mockito-interviewvragen Mockito Interview Vragen en antwoorden met voorbeeldcodevoorbeelden. Dit zal je helpen om elk Mockito Mocking Framework-interview met succes te kraken. |
Laten we beginnen met de eerste tutorial in deze serie !!
Wat je leert:
- Bespotten bij het testen van eenheden
- Typen / categorieën testdubbels
- Verschillende spottende kaders
- Broncode
- Gevolgtrekking
- Aanbevolen literatuur
Bespotten bij het testen van eenheden
Mocks / Stubs is een term die mensen vaak horen tijdens het maken van unit-tests in het bijzonder.
Dus, wat is in wezen bespotten? In eenvoudige bewoordingen is het niets anders dan het bieden van een gecontroleerde instantie of implementatie van afhankelijkheid waarvan de te testen code afhankelijk is om de kernlogica te testen.
De reden dat ik het als een gecontroleerde instantie noemde, is dat het gedrag van de afhankelijkheid naar wens kan worden geprogrammeerd of gecontroleerd voor de methode of het systeem dat wordt getest.
Laten we, om het diagrammatisch uit te leggen, een voorbeeld nemen van een zakelijke of e-commercetoepassing. Bijna elk type applicatie heeft voornamelijk 3 lagen, d.w.z. Gebruikersinterface, bedrijfslaag en gegevenstoegangslaag (die praat met de onderliggende datastore)
Verwijzend naar het bovenstaande diagram, heeft Business Layer 3 afhankelijkheden, namelijk datatoegangslaag en 2 andere services, namelijk Service 1 en Service 2.
Bekijk het op deze manier: een app zoals Google Maps kan afhankelijk zijn van een
- Werkelijke gegevens worden opgeslagen zoals MySQL of een andere SQL-database die geen kaartgegevens opslaat.
- Een externe service zoals CoordinateService die de breedtegraden en lengtes van een locatie biedt.
- Een externe service, zoals verkeersinformatie, die realtime verkeersinformatie biedt voor een bepaald coördinatenpaar.
Dus als iemand de kernlogica van het bedrijf probeert te valideren met behulp van unit-test, kunnen de tests niet worden uitgevoerd totdat en tenzij ze werkende implementaties van deze afhankelijkheden hebben.
Mocks komen te hulp in deze situaties, waar ongeacht uw afhankelijkheid actief is of niet, u bent altijd gegarandeerd dat u uw bedrijfslogica uitvoert met een geprogrammeerd antwoord voor de afhankelijkheid die wordt opgeroepen vanuit de code die wordt getest.
Typen / categorieën testdubbels
Mock is in wezen een soort 'Test Double' - het is een technisch jargon. 'Test Double' betekent in wezen een object dat wordt vervangen door een equivalente echte objectinstantie of afhankelijkheid.
Er zijn verschillende soorten testverdubbelingen, zoals hieronder vermeld:
# 1) Vervalsingen:
Een nep is een werkende implementatie die lijkt op een echte afhankelijkheid, behalve dat deze lokaal is voor het systeem dat wordt getest.
Voorbeeld: In plaats van een echte productie-database te raken, gebruikt de test een eenvoudige verzameling / in-memory om gegevens op te slaan.
# 2) Stompjes:
Stubs zijn vooraf geconfigureerde reacties wanneer een afhankelijkheid wordt aangeroepen vanuit het te testen systeem.
# 3) Spionnen:
Zoals de naam suggereert, is het eigenlijk de echte functie (afhankelijkheid) aanroep met een of ander observatiemechanisme. Plaats de oproep, samen met de parameters kan worden gecontroleerd of de oproep daadwerkelijk is geactiveerd of niet.
# 4) Spot:
Mocks zijn speciale instanties van objecten, waarop Stubbed / vooraf geconfigureerde reacties kunnen worden gespecificeerd. Het feit dat de mock werd opgeroepen, kan worden geverifieerd als een bewering in de test.
Bijvoorbeeld:
Er is een rapportgeneratorfunctie die tijdens de uitvoering een e-mail naar een opgegeven adres stuurt.
Omdat we tijdens het testen niet keer op keer echte e-mail willen verzenden, wordt de EmailService bespot (en de e-mailmethode die de e-mail verzendt, is geconfigureerd om niets te doen wanneer deze wordt gebeld). Aan het einde van de test kunnen we gewoon verifiëren dat de e-mailverzendmethode van de e-mailservice is aangeroepen via het bespotte object.
Verschillende spottende kaders
Bijna alle talen bieden verschillende soorten spottende kaders. We zullen een voorbeeldcode schrijven met Mockito, een open source mocking-framework voor Java.
Anatomie van een eenvoudige unit-test met bespotte afhankelijkheid. Stel dat we een applicatie proberen te testen die het totaal aantal punten voor een student in alle vakken berekent en naar DB schrijft.
Als we nu een eenheidstest willen schrijven voor de methode - berekenSumAndStore, dan hebben we misschien geen echte implementatie van een database om het totaal op te slaan. In dat geval kunnen we deze functie nooit unit testen.
Maar met spotjes kunnen we gewoon een Mock voor databaseservice doorgeven en de rest van de logica valideren
Voorbeeldtest zoals hieronder weergegeven:
We hebben in de bovenstaande test gezien dat we een mockDatabase-object hebben geleverd aan de bovenliggende klasse (voor de methode die wordt getest) en we hebben een stub-antwoord ingesteld voor het mockedDatabase-object - regel # 6 hierboven (Mockito.doNothing (). When (mockDatabase) .updateScores ('student1', 220);)
De belangrijke punten om op te merken uit het bovenstaande zijn:
# 1) Het bespotte object moet gestubde reacties instellen voor alle methoden die worden aangeroepen tijdens de uitvoering van de functie.
#twee) De parameters die zijn opgegeven tijdens het maken van stubs kunnen specifiek of algemeen zijn.
Voorbeeld in het bovenstaande geval - hebben we de parameters voor de updateScores-methode gespecificeerd als “student1” en 220 omdat we weten dat dit de exacte invoer is waarmee onze methode zal worden aangeroepen.
# 3) Tijdens verificatie valideren we het volgende:
- De methode mockDatabase.updateScores is aangeroepen.
- Argumenten waren respectievelijk “student1” & 220.
- De updateScores-methode werd 1 keer aangeroepen.
Laten we nu proberen deze testcode een beetje te wijzigen en kijken wat er gebeurt:
Ik zal het argument in de mock-setup wijzigen van 'student1' naar anyString (Mockito biedt een standaard matcher met de naam anyString ()) & 220 naar anyInteger (Mockito biedt een standaard matcher met de naam anyInt () en het komt overeen met elke gehele waarde)
Probeer de test opnieuw uit te voeren en de test moet nog steeds groen zijn.
(Laten we nu proberen de verificatie / beweringen te wijzigen en een van de argumenten te wijzigen.
Laten we 220 veranderen in 230. Nu is de verwachting dat de test zal mislukken, aangezien dit niet het verwachte argument is waarmee de databaseUpdate moet zijn aangeroepen.
Raadpleeg na het uitvoeren van de test de foutenlogboeken zoals hieronder weergegeven (het vermeldt duidelijk dat de werkelijke argumenten niet overeenkwamen met de verwachte).
Argument (en) zijn anders! Gezocht:
mockDatabase.updateScores ('student1', 230);
-> op com.mocking.sampleMocks.StudentScoreUpdatesUnitTests.calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb (StudentScoreUpdatesUnitTests.java:37)
Werkelijke aanroep heeft verschillende argumenten:
mockDatabase.updateScores ('student1', 220);
Broncode
Interface - IDatabase.java
Klasse wordt getest - StudentScoreUpdates.java
Unit Tests Class - StudentScoreUpdatesUnitTests.java
Gevolgtrekking
Wat we tot nu toe hebben gezien, is een heel eenvoudig en duidelijk voorbeeld van de Mock-installatie met behulp van het Mockito-framework van Java.
Voor bijna 60-70% van de eenheidstests met bespottingen moeten de tests een vergelijkbare structuur hebben. Mockito biedt veel geavanceerde configuratie / ondersteuning voor uitgebreide mocking-behoeften, waarbij nepinstances worden geïnjecteerd met behulp van afhankelijkheidsinjectie, waardoor Spies daadwerkelijk een echte methodeaanroep kan bespioneren en de oproepen kan verifiëren.
Onze aanstaande tutorial zal meer uitleggen over het concept van Mocks and Spies in Mockito.
Aanbevolen literatuur
- Top 12 Mockito-interviewvragen (Mocking Framework-interview)
- Diepgaande Eclipse-zelfstudies voor beginners
- Het Node.js-testframework instellen: Node.js-zelfstudie
- Unit-tests schrijven met Spock Framework
- De verschillen tussen unit-tests, integratietests en functionele tests
- Beste softwaretesttools 2021 (QA Test Automation Tools)
- Tutorial over destructief testen en niet-destructief testen
- Functioneel testen versus niet-functioneel testen