JMockit 101

1. Introduktion

Med denne artikel starter vi en ny serie centreret omkring det spottende værktøjssæt JMockit.

I denne første rate taler vi om, hvad JMockit er, dets egenskaber og hvordan mocks oprettes og bruges sammen med det.

Senere artikler vil fokusere på og gå dybere ind i dets evner.

2. JMockit

2.1. Introduktion

Lad os først tale om, hvad JMockit er: en Java-ramme til mocking af objekter i test (du kan bruge den til både JUnit og TestNG).

Det bruger Java's instrumenterings-API'er til at ændre klassernes bytecode under runtime for at ændre deres adfærd dynamisk. Nogle af dets stærke sider er dets ekspressibilitet og dets out-of-the-box evne til at spotte statiske og private metoder.

Måske er du ny hos JMockit, men det skyldes bestemt ikke, at det er nyt. JMockits udvikling startede i juni 2006 og dens første stabile udgivelsesdatoer til december 2012, så det har eksisteret i et stykke tid nu (den nuværende version er 1.24 på tidspunktet for artiklens skrivning).

2.2. Maven afhængighed

Først skal vi tilføje jmockit-afhængighed til vores projekt:

 org.jmockit jmockit 1.41 

2.3. Ekspressionen af ​​JMockit

Som fortalt før er et af JMockits stærkeste punkter dets ekspressibilitet. For at skabe mocks og definere deres adfærd, skal du bare definere dem direkte i stedet for at kalde metoder fra mocking API.

Dette betyder, at du ikke vil gøre ting som:

API.expect (mockInstance.method ()). OgThenReturn (værdi) .tider (2);

I stedet forventer ting som:

ny forventning () {mockInstance.method (); resultat = værdi; gange = 2; }

Det ser ud til, at det er mere kode, men du kan simpelthen sætte alle tre linjer bare på en. Den virkelig vigtige del er, at du ikke ender med et stort ”tog” af lænkede metodeopkald. I stedet ender du med en definition af, hvordan du ønsker, at mocken skal opføre sig, når den kaldes.

Hvis du tager højde for det på resultat = værdi del du kunne returnere hvad som helst (faste værdier, dynamisk genererede værdier, undtagelser osv.), bliver JMockits udtryksevne endnu mere tydelig.

2.4. Record-Replay-Verify-modellen

Test ved hjælp af JMockit er opdelt i tre differentierede faser: optag, gentag og bekræft.

  1. På den optage fase, under testforberedelse og inden påkaldelsen af ​​de metoder, vi vil udføre, definerer vi den forventede adfærd for alle tests, der skal bruges i næste trin.
  2. Det afspilning fase er den, hvor koden under test udføres. Påkaldelsen af ​​hånede metoder / konstruktører, der tidligere er optaget på den forrige fase, vil nu blive spillet igen.
  3. Endelig på verificere fase, vil vi hævde, at resultatet af testen var det, vi forventede (og at mocks opførte sig og blev brugt i henhold til det, der blev defineret i recordfasen).

Med et kodeeksempel vil en trådramme til en test se sådan ud:

@Test public void testWireframe () {// forberedelseskode ikke specifik for JMockit, hvis der er nye Expectations () {{// definerer forventet adfærd for mocks}}; // udføre kode under test nye verifikationer () {{// verificere mocks}}; // påstande}

3. Oprettelse af mocks

3.1. JMockits kommentarer

Når du bruger JMockit, er den nemmeste måde at bruge mocks på at bruge kommentarer. Der er tre til oprettelse af mocks (@Drillet, @Injicerbar og @Capturing) og en til at specificere den klasse, der testes (@Testet).

Når du bruger @Drillet kommentar på et felt, vil det skabe spottede forekomster af hvert eneste nye objekt i den pågældende klasse.

På den anden side med @Injicerbar kommentar, kun en mocked forekomst oprettes.

Den sidste kommentar, @Capturing vil opføre sig som @Drillet, men vil udvide rækkevidden til enhver underklasse, der udvider eller implementerer typen af ​​det kommenterede felt.

3.2. Videregivelse af argumenter til test

Når du bruger JMockit er det muligt at overføre mocks som testparametre. Dette er ret nyttigt til oprettelse af en mock kun til den ene test i særdeleshed, som et komplekst modelobjekt, der f.eks. Har brug for en bestemt adfærd kun til en test. Det ville være sådan noget:

@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åde at oprette en mock på ved at sende den som en parameter i stedet for at skulle kalde en API-metode, viser os igen ekspressibiliteten, vi taler om siden starten.

3.3. Komplet eksempel

For at afslutte denne artikel inkluderer vi et komplet eksempel på en test ved hjælp af JMockit.

I dette eksempel tester vi en Kunstner klasse, der bruger Samarbejder i dets udføre() metode. Det her udføre() metode, modtager en Model objekt som en parameter, hvorfra den vil bruge dens få information() der returnerer en streng, sendes denne streng til samarbejde() metode fra Samarbejder der vender tilbage rigtigt til denne særlige test, og denne værdi overføres til modtage() metode fra Samarbejder.

Så de testede klasser vil se sådan ud:

public class Model {public String getInfo () {return "info"; }} public class Collaborator {public boolean collaborate (String string) {return false; } offentlig ugyldig modtagelse (boolsk bool) {// NOOP}} offentlig klasse Performer {privat Collaborator-samarbejdspartner; public void perform (Model model) {boolean value = collaborator.collaborate (model.getInfo ()); collaborator.receive (værdi); }}

Og testens kode vil ende med at blive som:

@RunWith (JMockit.class) offentlig klasse PerformerTest {@Injectable private Collaborator collaborator; @Tested privat performer performer; @Test offentlig ugyldighedstestThePerformMethod (@Mocked Model model) {new Expectations () {{model.getInfo (); result = "bar"; collaborator.collaborate ("bar"); resultat = sandt; }}; performer.perform (model); nye verifikationer () {{collaborator.receive (true); }}; }}

4. Konklusion

Med dette afslutter vi vores praktiske introduktion til JMockit. Hvis du vil lære mere om JMockit, skal du holde øje med fremtidige artikler.

Den fulde implementering af denne vejledning kan findes på GitHub-projektet.

4.1. Artikler i serien

Alle artikler i serien:

  • JMockit 101
  • En guide til JMockit - forventninger
  • JMockit avanceret brug

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