Menu

Spock Mocking and Stubbing (voorbeelden met videotutorials)

  • Hoofd
  • Andere
  • Spock Mocking and Stubbing (voorbeelden met videotutorials)

spock mocking stubbing

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Bespotten, stoten en bespioneren met Spock:

Geparametriseerd testen in Spock Framework werd hierin uitgebreid toegelicht Serie trainingshandleidingen over Spock ​

Mocking en Stubbing zijn een van de meest essentiële bouwstenen van uitgebreide unit-tests. Ondersteuning voor spot en subbing is als de kers op de taart voor een kader.

Voor bestaande frameworks zoals JUnit, JBehave, enz. Komt de ondersteuning voor spotjes en stubs niet uit de doos, daarom is het vereist dat een ontwikkelaar bibliotheken van derden zoals Mockito, PowerMock, EasyMock, enz. Gebruikt om ze in de eenheidstests.

SPOTEN, STUBBEREN EN SPYEN

Om spotjes en stubs en hun gebruikssituaties te begrijpen, kunt u een kijkje nemen in onze Serie van Mockito-zelfstudie ​

In deze tutorial zullen we meer leren over de ingebouwde Mocking- en Stubbing-functies die zijn geïntegreerd in de Spock-bibliotheek zelf, die op hun beurt het gebruik van de eenvoudigere Groovy-syntaxis mogelijk maken en daardoor de noodzaak verminderen om andere 3 toe te voegen / toe te voegen.rdpartijbibliotheken.

U kunt altijd andere Mocking-frameworks in uw tests opnemen, aangezien alle geldige Java-code ook geldige Groovy-code is.

Wat je leert:

Toepassing wordt getest

Laten we eerst een voorbeeld van een Java-applicatie definiëren, die we gaan testen met behulp van mocks en stubs in het Spock-framework.

We werken aan een StudentGradeCalculator-app die de totale score haalt uit een geabstraheerde database voor een bepaalde student-ID en een eenvoudige logica heeft voor het toekennen van cijfers, afhankelijk van de waarde van de totale score. We zullen een database-interface gebruiken die weinig methoden heeft om de scores en cijfers van studenten op te halen en bij te werken.

hoe je een multidimensionale array in java declareert

De code voor de applicatie is beschikbaar in het laatste deel van deze tutorial.

Spottend in Spock

Video-instructies

In deze sectie zullen we zien hoe Mocks in het Spock-raamwerk geïnstantieerd en geïnitialiseerd kunnen worden en hoe interacties op de mock kunnen gevalideerd worden, d.w.z. validatie van de oproepen naar de Mocks gebeurde volgens de verwachtingen van de geteste methode.

Met Mocks hoeft u niet veel instellingen uit te voeren, maar u kunt de interacties valideren die hebben plaatsgevonden met de nepobjecten die aan de te testen applicatie zijn geleverd.

Met spot kunt u dingen doen als:

  • Met welke argumenten werden de spotprenten opgeroepen?
  • Wat was het totale aantal aanroepen enz.?
  • De volgorde van de spot bepalen.

Laten we eens kijken naar een eenvoudig voorbeeld van de StudentGradeCalculator, waar we het nagemaakte database-implementatie-object leveren en de interacties met de Mock valideren. We zullen proberen de spottende functies te begrijpen met eenvoudige voorbeelden.

Houd er rekening mee dat alle interactievalidaties volgens afspraak in het 'toen' -blok moeten plaatsvinden.

Hieronder staat de code voor de methode die wordt getest (die wordt genoemd in de ' wanneer: 'Blok)

​

# 1) De interacties valideren met exacte argumenten: laten we eerst de interacties valideren met de exact verwachte argumenten. Hier zullen we verwachten dat de bespotte methoden worden aangeroepen met de exacte argumenten (volgens de methode-uitvoeringsstroom).

Hier ' studentDatabase ”Is de schijn van een database-interface waarvoor we de interacties valideren.

​

Zoals hierboven getoond, valideren we met de exacte argumenten, zodat de bespotte implementatie moet zijn aangeroepen. Elke wijziging van deze argumenten zorgt ervoor dat de test mislukt en het foutenlogboek toont de juiste reden.

Laten we proberen het cijfer te wijzigen in ' updateStudentGrade ”Naar“ A ”in plaats van de eigenlijk“ C ”genaamd en kijk welke fout we krijgen als de test wordt uitgevoerd.

​

Het zal een foutmelding geven als 'Te weinig aanroepen' omdat het de Mock-aanroep met de opgegeven argumenten niet kan vinden.

#twee) Laten we nu eens kijken hoe we de mock-interacties kunnen valideren zonder de werkelijke argumentwaarden op te geven, d.w.z. waar we in geïnteresseerd zijn, is gewoon weten dat de mock-up op de methode is aangeroepen, maar niet met welke argumenten.

Dit soort vereisten komen het meest voor bij het schrijven van unit-tests voor de daadwerkelijke productiecode, aangezien het niet altijd gemakkelijk is om de daadwerkelijke argumenten te identificeren die in wezen afhangen van de kernlogica van de te testen applicatie.

De syntaxis is eenvoudig, u hoeft alleen een onderstrepingsteken '_' te gebruiken voor een argument waarvan de werkelijke waarde niet bekend is.

Bijvoorbeeld, om te controleren op een String-waarde, kunt u gewoon vermelden '_ Als String ”In de plaats van een argument in de test en het zou moeten doorgaan voor elke String-waarde (vergelijkbaar voor andere primitieve en aangepaste gegevenstypen).

Laten we dit begrijpen met een voorbeeld

​

Een belangrijk punt om op te merken is dat je altijd kunt mixen en matchen voor welke argumenten bekend zijn en wat niet. In het onderstaande voorbeeld valideren we bijvoorbeeld de interactie van de ene mock met de werkelijke argumenten en de andere met de losse matchers.

# 3) Laten we tot slot een scenario bekijken waarin we de volgorde van de schijnaanroep kunnen vaststellen, d.w.z. in welke volgorde de schijnwerpers werden genoemd toen de test werd uitgevoerd.

Het is soms essentieel om de stroom van gebeurtenissen te valideren wanneer er meerdere medewerkers / schijnwerpers bij de te testen applicatie betrokken zijn en het is nuttig om te begrijpen en te valideren dat de methoden in een vooraf bepaalde volgorde zijn aangeroepen.

​

Dit kan worden bereikt door simpelweg meerdere 'dan:' -blokken te gebruiken in de volgorde van de verwachtingen van de onechte reeks. Als de genoemde volgorde niet voldeed aan de daadwerkelijke aanroepvolgorde, wordt er een fout gegenereerd met de vermelding 'Verkeerde aanroepvolgorde'.

Als ik bijvoorbeeld de volgorde van het bovenstaande verander vervolgens statements, genereert de testuitvoering een fout zoals hieronder weergegeven.

​

Stubbing in Spock

Video-instructies

beste software voor het herstellen van externe harde schijven

We hebben alles over bespotten onderzocht, laten we nu kijken hoe we stubs op de bespotte objecten kunnen definiëren. Stubbing is niets anders dan het instellen van vooraf gedefinieerde of standaardantwoorden op de nep-aanroepen om de verschillende stromen / scenario's van de te testen applicatie te testen.

Zie het als het programmeren van een mock om een ​​vooraf gedefinieerde waarde te retourneren wanneer deze werd aangeroepen. We gaan door met dezelfde StudentGradeCalculator-app en stub de database-interface-aanroepen om verschillende scenario's te testen.

Een Stub is als een Mock die in zekere zin het gedrag van het echte object nabootst. Je kunt het gewoon een geprogrammeerde Mock noemen.

Syntaxis afbreken

De syntaxis voor stubbing is 2 rechts-shift-operators, d.w.z. ' ​ ​

Om een ​​steeklijn voor een oproep in te stellen, kunt u deze als volgt definiëren:

​

Laten we nu de verschillende stubbing-scenario's bekijken met voorbeelden.

# 1) Stoppen met actuele parameters: Als de argumenten van tevoren bekend zijn of als u stub alleen wilt instellen wanneer de aanroep met gespecificeerde argumenten is, kan deze manier van specificeren van stubs worden gebruikt.

​

Hier kun je zien dat de stub is ingesteld met een exact argument, d.w.z. StudentId in dit geval als '123' (voor elke andere waarde wordt de stub niet aangeroepen en zal er een standaardantwoord worden geretourneerd).

# 2) Stoppen met milde matchers: Als de argumenten niet bekend zijn (of niet belangrijk zijn), dan kunnen we ze losjes noemen zoals we deden voor schijnvertoningen en de syntaxis blijft hetzelfde, d.w.z. het onderstrepingsteken '_'.

​

# 3) Laten we nog een snel voorbeeld bekijken waarin we een stub hebben ingesteld om een ​​uitzondering te genereren.

Deze scenario's zijn erg handig om de foutafhandelingslogica van een te testen applicatie te valideren (net als in de echte wereld is het genereren van alle uitzonderingen eigenlijk niet mogelijk, maar een eenvoudige stub kan worden ingesteld om elke gewenste uitzondering te retourneren en deze vervolgens te bevestigen in het dan blok).

​

Spioneren in Spock

Spionnen zijn gebaseerd op echte objecten d.w.z. ze hebben de interface-implementatie nodig en niet de abstracte interface zelf. Spionnen zijn krachtig en kunnen u in staat stellen om echte methoden te krijgen die worden opgeroepen voor de te testen applicatie en om te verifiëren voor welke argumenten de methoden nodig zijn.

Spionnen maken het ook mogelijk om gedeeltelijke bespotten op de bespioneerde objectinstanties te definiëren. d.w.z. stel dat u het gedrag van sommige methoden op het object wilt definiëren, dan kunt u en toestaan ​​dat de rest wordt aangeroepen als echte methode-aanroepen.

Deze zijn meestal handig in een situatie waarin sommige interfacemethoden mogelijk niet zijn geïmplementeerd en er zijn er enkele die volledig functioneel zijn. Daarom kunt u als ontwikkelaar ervoor kiezen om de niet-geïmplementeerde methoden te stubben en de echte implementaties van de functionele methoden aan te roepen.

Opgemerkt moet worden dat, voor bespioneerde objecten, tenzij stubs zijn gedefinieerd, het standaardgedrag is om de echte implementatie aan te roepen. Dat gezegd hebbende, mogen spionnen niet vaak worden gebeld en kan alle scenariodekking worden bereikt met behulp van spotjes en stubs en een combinatie daarvan.

Laten we een paar voorbeelden bekijken van het gebruik van Spies in het Spock-framework met hetzelfde voorbeeld van StudentGradeCalculator (We hebben een echte implementatie gemaakt van de StudentDatabase wat een in-memory implementatie is met Hash kaart om het aanroepen van echte methoden en het retourneren van gegevens te illustreren. De code is beschikbaar in het laatste deel van de tutorial):

# 1) Spioneren met een combinatie van stub en echte methodeaanroepen

​

Het bovenstaande voorbeeld illustreert de syntaxis voor het maken van Spy met behulp van het Spock-framework. De stub wordt gedefinieerd op het aangiftetijdstip zelf.

Ook kunnen de bespioneerde oproepen worden geverifieerd zoals geïllustreerd in het then-blok (met losse argument-matchers die kunnen worden gedefinieerd voor elk specifiek argument).

# 2) Spioneren met behulp van alle echte methodeaanroepen

​

In het bovenstaande voorbeeld, omdat we geen stoppend gedrag hebben genoemd, gaan alle oproepen naar de echte implementatie.

Gevolgtrekking

In deze tutorial hebben we alles geleerd over de ingebouwde technieken om Stub en Spy te bespotten met behulp van het Spock-framework. Spock maakt het gemakkelijk door deze functies te combineren als onderdeel van het framework zelf met een beter leesbare groovy syntaxis samen met de mindere standaardcode.

Mocks, Stubs en Spies worden op grote schaal gebruikt bij het testen van eenheden voor het vergroten van de dekking en het testen of valideren van de kernlogica van de te testen applicatie.

Broncode voor de applicatie

StudentReportGenerator.java - dit is de methode / applicatie die wordt getest

​

IStudentDatabase.java - Database-interface

​

StudentDatabase.java - InMemory implementatie van de IStudentDatabase.java interface

​

In onze aanstaande tutorial zullen we zien hoe we het Spock-framework kunnen integreren met andere testframeworks en technologieën.

PREV-zelfstudie ​ VOLGENDE zelfstudie

Aanbevolen literatuur

^