JMockit 101

1. Introduksjon

Med denne artikkelen skal vi starte en ny serie sentrert rundt den spottende verktøysettet JMockit.

I denne første delen vil vi snakke om hva JMockit er, dens egenskaper og hvordan mocks blir opprettet og brukt sammen med den.

Senere artikler vil fokusere på og gå dypere inn i dens evner.

2. JMockit

2.1. Introduksjon

La oss først og fremst snakke om hva JMockit er: et Java-rammeverk for å spotte objekter i tester (du kan bruke det til både JUnit og TestNG).

Den bruker Javas instrumenterings-API-er for å endre klassens bytekode under kjøretid for å endre oppførselen dynamisk. Noen av dets sterke sider er ekspressibiliteten og dens evne til å spotte statiske og private metoder.

Kanskje du er ny i JMockit, men det skyldes absolutt ikke at den er ny. JMockits utvikling startet i juni 2006 og den første stabile utgivelsesdatoen til desember 2012, så den har eksistert en stund nå (den nåværende versjonen er 1.24 når artikkelen skrives).

2.2. Maven avhengighet

Først må vi legge til jmockit-avhengigheten til prosjektet vårt:

 org.jmockit jmockit 1.41 

2.3. Uttrykbarheten til JMockit

Som før fortalt er et av de sterkeste punktene i JMockit dets uttrykbarhet. For å lage mocks og definere deres atferd, i stedet for å ringe metoder fra mocking API, trenger du bare å definere dem direkte.

Dette betyr at du ikke vil gjøre ting som:

API.expect (mockInstance.method ()). AndThenReturn (value) .times (2);

I stedet kan du forvente ting som:

ny forventning () {mockInstance.method (); resultat = verdi; ganger = 2; }

Det kan virke som om det er mer kode, men du kan bare sette alle tre linjene bare på en. Den veldig viktige delen er at du ikke ender opp med et stort "tog" med lenkeformede samtaler. I stedet ender du opp med en definisjon av hvordan du vil at mocken skal oppføre seg når den blir ringt.

Hvis du tar hensyn til det på resultat = verdi del du kunne returnere hva som helst (faste verdier, dynamisk genererte verdier, unntak osv.), blir uttrykksevnen til JMockit enda tydeligere.

2.4. Record-Replay-Verify-modellen

Tester med JMockit er delt inn i tre differensierte stadier: spille inn, spille på nytt og verifisere.

  1. ta opp fase, under testforberedelsen og før påkallingen til metodene vi vil utføre, vil vi definere forventet oppførsel for alle testene som skal brukes i neste trinn.
  2. De avspilling fase er den koden som testes utføres i. Innkallingene til spottede metoder / konstruktører som tidligere er spilt inn på forrige scene vil nå bli spilt på nytt.
  3. Til slutt, på bekrefte fase, vil vi hevde at resultatet av testen var det vi forventet (og at mocks oppførte seg og ble brukt i henhold til det som ble definert i postfasen).

Med et kodeeksempel vil en trådramme for en test se ut slik:

@Test public void testWireframe () {// forberedelseskode ikke spesifikk for JMockit, hvis noen nye Expectations () {{// definerer forventet oppførsel for mocks}}; // utføre kode under test nye bekreftelser () {{// verifisere mocks}}; // påstander}

3. Opprette Mocks

3.1. JMockits kommentarer

Når du bruker JMockit, er den enkleste måten å bruke mocks på, å bruke kommentarer. Det er tre for å lage mocks (@Latterliggjort, @Injiserbar og @Fangst) og en for å spesifisere klassen som testes (@Testet).

Når du bruker @Latterliggjort merknad på et felt, vil det skape spottede forekomster av hvert eneste nye objekt i den aktuelle klassen.

På den annen side, med @Injiserbar kommentar, bare en spottet forekomst vil bli opprettet.

Den siste kommentaren, @Fangst vil oppføre seg som @Latterliggjort, men vil utvide rekkevidden til alle underklasser som utvider eller implementerer typen for kommenterte felt.

3.2. Gi argumenter til tester

Når du bruker JMockit er det mulig å overføre mocks som testparametere. Dette er ganske nyttig for å lage en mock bare for den ene testen spesielt, som et komplekst modellobjekt som trenger en spesifikk oppførsel bare for en test for eksempel. Det ville være noe slikt:

@RunWith (JMockit.class) offentlig klasse TestPassingArguments {@Injectable private Foo mockForEveryTest; @ Testet privat barbar; @Test public void testExample (@Mocked Xyz mockForJustThisTest) {new Expectations () {{mockForEveryTest.someMethod ("foo"); mockForJustThisTest.someOtherMethod (); }}; bar.codeUnderTest (); }}

Denne måten å lage en mock på ved å sende den som en parameter, i stedet for å måtte kalle noen API-metoder, viser oss igjen ekspressibiliteten vi snakker om siden begynnelsen.

3.3. Komplett eksempel

For å avslutte denne artikkelen inkluderer vi et komplett eksempel på en test med JMockit.

I dette eksemplet skal vi teste a Utøver klasse som bruker Samarbeider i sin utføre() metode. Dette utføre() metode, mottar en Modell objekt som en parameter som den vil bruke sin fra få informasjon() som returnerer en streng, vil denne strengen bli sendt til samarbeide() metode fra Samarbeider som kommer tilbake ekte for denne spesielle testen, og denne verdien vil bli gitt til motta() metode fra Samarbeider.

Så de testede klassene vil se slik ut:

public class Model {public String getInfo () {return "info"; }} public class Collaborator {public boolean collaborate (String string) {return false; } public void receive (boolean bool) {// NOOP}} public class Performer {private Collaborator collaborator; public void perform (Model model) {boolean value = collaborator.collaborate (model.getInfo ()); samarbeidspartner. motta (verdi); }}

Og testens kode vil ende opp som:

@RunWith (JMockit.class) offentlig klasse PerformerTest {@Injectable private Collaborator collaborator; @ Testet privat utøver utøver; @Test offentlig ugyldig testThePerformMethod (@Mocked Model model) {new Expectations () {{model.getInfo (); result = "bar"; collaborator.collaborate ("bar"); resultat = sant; }}; performer.perform (modell); nye bekreftelser () {{collaborator.receive (true); }}; }}

4. Konklusjon

Med dette vil vi avslutte vår praktiske intro til JMockit. Hvis du vil lære mer om JMockit, kan du følge med på fremtidige artikler.

Den fulle implementeringen av denne veiledningen finner du på GitHub-prosjektet.

4.1. Artikler i serien

Alle artiklene i serien:

  • JMockit 101
  • En guide til JMockit - forventninger
  • JMockit avansert bruk

$config[zx-auto] not found$config[zx-overlay] not found