Meni

Ismijavanje privatnih, statičkih i praznih metoda korištenjem Mockita

  • Glavni
  • Ostalo
  • Ismijavanje privatnih, statičkih i praznih metoda korištenjem Mockita

mocking private static

Isprobajte Naš Instrument Za Uklanjanje Problema

Naučite ruganje privatnim, statičkim i praznim metodama u Mockitu na primjerima:

U ovoj seriji praktičnih Vodiči o Mockitu , pogledali smo različite vrste Mockito Matchera u zadnjem tutorialu.

Općenito govoreći, ruganje privatnim i statičkim metodama spada u kategoriju neobičnog ruganja.

Ako se pojavi potreba za izrugivanjem privatnih i statičkih metoda / klasa, to ukazuje na loše prepravljeni kôd i zapravo nije provjerljivi kôd, a najvjerojatnije je da je riječ o nekom naslijeđenom kodu koji nije bio vrlo prilagođen jedinstvenom testu.

Imajući to u vidu, još uvijek postoji podrška za ruganje privatnim i statičkim metodama od strane nekoliko okvira za jedinstveno testiranje poput PowerMockita (a ne izravno od Mockita).

Privatne, statičke i praznine metode ruganja u Mockitu

Ismijavanje metoda „void“ uobičajeno je, jer možda postoje metode koje u suštini ne vraćaju ništa, poput ažuriranja retka baze podataka (smatrajte to operacijom PUT krajnje točke Rest API-ja koja prihvaća ulaz i ne vraća izlaz).

Mockito pruža potpunu podršku za ruganje praznim metodama, što ćemo vidjeti sa primjerima u ovom članku.

pitanja i odgovori za cisco mrežni intervju pdf

Što ćete naučiti:

Powermock - Kratki uvod

Za Mockito ne postoji izravna podrška za ruganje privatnim i statičkim metodama. Da biste testirali privatne metode, morat ćete refaktor koda da biste promijenili pristup zaštićenom (ili paketu) i morat ćete izbjeći statičke / konačne metode.

Po mojem mišljenju Mockito namjerno ne pruža podršku za ove vrste podsmjeha, jer su korištenje ovih vrsta konstrukcija koda mirisi koda i loše dizajniran kôd.

Ali, postoje okviri koji podržavaju ruganje privatnim i statičkim metodama.

Powermock proširuje mogućnosti drugih okvira poput EasyMocka i Mockita te pruža mogućnost ismijavanja statičkih i privatnih metoda.

# 1) Kako: Powermock to čini uz pomoć prilagođene manipulacije bajt kodom kako bi podržao ruganje privatnim i statičkim metodama, završnim klasama, konstruktorima i tako dalje.

# 2) Podržani paketi: Powermock nudi 2 API-ja za proširenje - jedan za Mockito i jedan za easyMock. Radi ovog članka napisat ćemo primjere s Mockito nastavkom za power mock.

# 3) Sintaksa :Powermockito ima gotovo sličnu sintaksu kao Mockito, osim nekih dodatnih metoda za ruganje statičkim i privatnim metodama.

# 4) Postavljanje Powermockito

Da bi se Mockito knjižnica uključila u projekte temeljene na gradle-u, slijede knjižnice koje treba uključiti:

testCompile group: 'org.powermock', name: 'powermock-api-mockito2', version: '1.7.4' testCompile group: 'org.powermock', name: 'powermock-module-junit4', version: '1.7.4'

Slične ovisnosti dostupne su i za maven.

Powermock-api-mockito2 - Knjižnica mora sadržavati Mockito proširenja za Powermockito.

Powermock-module-junit4 - Modul je potreban da sadrži PowerMockRunner (koji je prilagođeni pokretač koji se koristi za pokretanje testova s ​​PowerMockito).

Ovdje je važno napomenuti da PowerMock ne podržava Junit5 test runner. Stoga testove treba napisati protiv Junit4, a testove treba izvršiti pomoću PowerMockRunnera.

Da biste koristili PowerMockRunner - testnu klasu treba označiti @RunWith (PowerMockRunner.class)

Ajmo sad detaljno raspravljati, rugajući se privatnim, statičkim i praznim metodama!

Ismijavanje privatnih metoda

Izrugivanje privatnim metodama, koje se interno pozivaju iz metode koja se ispituje, u određeno vrijeme može biti neizbježno. Korištenjem powermockito-a to je moguće, a provjera se vrši novom metodom nazvanom ‘verifyPrivate’

Idemo uzeti anPrimjer gdje metoda koja se testira poziva privatnu metodu (koja vraća logičku vrijednost). Da bi se ova metoda vratila na tačno / netačno, ovisno o testu, na ovoj se klasi mora postaviti klinac.

Za ovaj Primjer, klasa koja se testira kreirana je kao špijunska instanca s ismijavanjem nekoliko poziva sučelja i pozivanja privatne metode.

Važne točke za Mock Private Method:

# 1) Metoda ispitivanja ili klasa ispitivanja moraju biti označeni sa @ PrepareForTest (ClassUnderTest). Ova napomena govori powerMockitu da pripremi određene klase za testiranje.

To će uglavnom biti oni razredi koji to trebaju biti Bytecode manipulira . Tipično za završne satove, predmeti koji sadrže privatne i / ili statičke metode kojima se treba rugati tijekom testiranja.

Primjer:

@PrepareForTest(PriceCalculator.class)

#dva) Za postavljanje kvara na privatnu metodu.

Sintaksa - when (lažna ili špijunska instanca, “privateMethodName”). thenReturn (// povratna vrijednost)

Primjer:

when (priceCalculatorSpy, 'isCustomerAnonymous').thenReturn(false);

# 3) Da biste provjerili privatnu metodu s ugrizom.

Sintaksa - verifyPrivate (mockedInstance) .invoke (“privateMethodName”)

Primjer:

verifyPrivate (priceCalculator).invoke('isCustomerAnonymous');

Kompletni testni uzorak: Nastavljajući isti primjer iz prethodnih članaka, gdje priceCalculator ima neke ismijane ovisnosti poput itemService, userService itd.

Stvorili smo novu metodu nazvanu - CalcuPriceWithPrivateMethod, koja poziva privatnu metodu unutar iste klase i vraća je li kupac anoniman ili ne.

@Test @PrepareForTest(PriceCalculator.class) public void calculatePriceForAnonymous_witStubbedPrivateMethod_returnsCorrectPrice() throws Exception { // Arrange ItemSku item1 = new ItemSku(); item1.setApplicableDiscount(5.00); item1.setPrice(100.00); double expectedPrice = 90.00; // Setting up stubbed responses using mocks when(priceCalculatorSpy, 'isCustomerAnonymous').thenReturn(false); when(mockedItemService.getItemDetails(123)).thenReturn(item1); // Act double actualDiscountedPrice = priceCalculatorSpy.calculatePriceWithPrivateMethod(123); // Assert verifyPrivate(priceCalculator).invoke('isCustomerAnonymous'); assertEquals(expectedPrice, actualDiscountedPrice); }

Ismijavanje statičkih metoda

Statičke metode mogu se rugati na sličan način kao što smo vidjeli kod privatnih metoda.

Kada metoda koja se testira uključuje upotrebu statičke metode iz iste klase (ili iz druge klase), morat ćemo je uključiti u napomenu pripremaForTest prije testa (ili u testnoj klasi).

Važne točke za lažne statičke metode:

# 1) Metoda ispitivanja ili klasa ispitivanja moraju biti označeni sa @ PrepareForTest (ClassUnderTest). Slično ruganju privatnim metodama / klasama, ovo je potrebno i za statičke klase.

#dva) Jedan dodatni korak koji je potreban za statičke metode je - mockStatic (// naziv statičke klase)

Primjer:

mockStatic(DiscountCategoryFinder.class)

# 3) Postavljanje stub-a na statičku metodu jednako je dobro kao i kicanje bilo koje metode na bilo kojem drugom lažnom primjeru sučelja / klase.

Na primjer: Da biste otupili getDiscountCategory () (koja vraća enum DiscountCategory sa vrijednostima PREMIUM & GENERAL) statičku metodu klase DiscountCategoryFinder, jednostavno stub na sljedeći način:

when (DiscountCategoryFinder. getDiscountCategory ()).thenReturn(DiscountCategory. PREMIUM );

# 4) Da biste provjerili lažnu postavku na konačnoj / statičkoj metodi, može se koristiti metoda verifyStatic ().

Primjer:

verifyStatic (DiscountCategoryFinder.class, times (1));

Podrugljive metode praznina

Pokušajmo prvo shvatiti kakve vrste slučajeva upotrebe mogu uključivati ​​ometajuće praznine:

# 1) Na primjer, pozivi metoda - koji tijekom postupka šalju obavijest e-poštom.

Na primjer :Pretpostavimo da promijenite lozinku za račun za internetsko bankarstvo, nakon uspješne promjene primit ćete obavijest putem e-pošte.

To se može smatrati / changePassword kao POST poziv Bank API-u koji uključuje poziv void metodom za slanje obavijesti e-poštom kupcu.

#dva) Još jedan uobičajeni primjer poziva void metode su ažurirani zahtjevi za DB koji uzimaju neke podatke i ne vraćaju ništa.

Metode zatvaranja praznina (tj. Metode koje ne vraćaju ništa ili izuzimaju iznimku) mogu se riješiti pomoću funkcije doNothing (), doThrow () i doAnswer (), doCallRealMethod () . Potrebno je postaviti klip koristeći gore navedene metode prema očekivanjima od testa.

Također, imajte na umu da se svi pozivi void metode prema zadanim postavkama izruguju doNothing (). Stoga, čak i ako eksplicitno lažno postavljanje nije izvršeno PONIŠTITI poziva metode, zadano ponašanje i dalje je doNothing ().

Pogledajmo primjere za sve ove funkcije:

Za sve primjere, pretpostavimo, postoji klasa StudentScoreUpdates koja ima metodu izračunajSumAndStore (). Ova metoda izračunava zbroj rezultata (kao ulaz) i poziva a poništiti metoda updateScores () na instanci implementacije baze podataka.

public class StudentScoreUpdates { public IDatabase databaseImpl; public StudentScoreUpdates(IDatabase databaseImpl) { this.databaseImpl = databaseImpl; } public void calculateSumAndStore(String studentId, int() scores) { int total = 0; for(int score : scores) { total = total + score; } // write total to DB databaseImpl.updateScores(studentId, total); } }

Napisat ćemo jedinstvene testove za poziv lažne metode sa sljedećim primjerima:

# 1) doNothing () - doNothing () je zadano ponašanje za pozive void metode u Mockitu, tj. Čak i ako potvrdite poziv metodom void (bez izričitog postavljanja praznine za doNothing (), provjera će i dalje biti uspješna)

public void calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb() { // Arrange studentScores = new StudentScoreUpdates(mockDatabase); int() scores = {60,70,90}; Mockito.doNothing().when(mockDatabase).updateScores(anyString(), anyInt()); // Act studentScores.calculateSumAndStore('student1', scores); // Assert Mockito.verify(mockDatabase, Mockito.times(1)).updateScores(anyString(), anyInt()); }

Ostale upotrebe uz doNothing ()

do) Kada se metoda void poziva više puta i želite postaviti različite odgovore za različite pozive, poput - doNothing () za prvi poziv i baciti iznimku na sljedeći poziv.

Na primjer :Postavite mock ovako:

Mockito. doNothing ().doThrow(new RuntimeException()).when(mockDatabase).updateScores( anyString (), anyInt ());

b) Kada želite uhvatiti argumente s kojima je pozvana metoda void, trebala bi se koristiti funkcionalnost ArgumentCaptor u Mockitu. To daje dodatnu provjeru argumenata s kojima je metoda pozvana.

Primjer s ArgumentCaptor:

public void calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb() { // Arrange studentScores = new StudentScoreUpdates(mockDatabase); int() scores = {60,70,90}; Mockito.doNothing().when(mockDatabase).updateScores(anyString(), anyInt()); ArgumentCaptor studentIdArgument = ArgumentCaptor.forClass(String.class); // Act studentScores.calculateSumAndStore('Student1', scores); // Assert Mockito.verify(mockDatabase, Mockito.times(1)).updateScores(studentIdArgument.capture(), anyInt()); assertEquals('Student1', studentIdArgument.getValue()); }

# 2) doThrow ()- Ovo je korisno kada jednostavno želite izuzeti kada se metoda void poziva iz metode koja se ispituje.

Na primjer:

Mockito.doThrow(newRuntimeException()).when(mockDatabase).updateScores ( anyString (), anyInt ());

# 3) doAnswer ()- doAnswer () jednostavno nudi sučelje za izvršavanje neke prilagođene logike.

Npr. Modificiranje neke vrijednosti putem proslijeđenih argumenata, vraćanje prilagođenih vrijednosti / podataka koje normalan klinac nije mogao vratiti, posebno za void metode.

U svrhu demonstracije - zaustavio sam void metodu updateScores () da vratim ' odgovor() ”I ispisati vrijednost jednog od argumenata koji je trebao biti proslijeđen kad je metoda trebala biti pozvana.

Primjer koda:

@Test public void calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb() { // Arrange studentScores = new StudentScoreUpdates(mockDatabaseImpl); int() scores = {60,70,90}; Mockito.doCallRealMethod().when(mockDatabaseImpl).updateScores(anyString(), anyInt()); doAnswer(invocation -> { Object() args = invocation.getArguments(); Object mock = invocation.getMock(); System.out.println(args(0)); return mock; }).when(mockDatabaseImpl).updateScores(anyString(), anyInt()); // Act studentScores.calculateSumAndStore('Student1', scores); // Assert Mockito.verify(mockDatabaseImpl, Mockito.times(1)).updateScores(anyString(), anyInt()); }

# 4) doCallRealMethod ()- Djelomični izrugivanja slični su otrcanjima (gdje neke metode možete nazvati stvarnim metodama, a ostale ukloniti).

Za void metode, mockito nudi posebnu funkciju nazvanu doCallRealMethod () koja se može koristiti kada pokušavate postaviti lažni obrazac. Što će ovo učiniti, pozvati će metodu real void sa stvarnim argumentima.

Na primjer:

Mockito. doCallRealMethod ().when(mockDatabaseImpl).updateScores( anyString (), anyInt ());

savjeti i trikovi

# 1) Uključivanje više statičkih klasa u istu testnu metodu / klasu- Korištenje PowerMockita ako postoji potreba za ismijavanjem višestruke Static of Final nastave onda nazivi klasa u @ PrepareForTest napomena se može spomenuti kao vrijednost odvojena zarezom kao niz (u osnovi prihvaća niz imena klasa).

što su metapodaci u skladištu podataka

Primjer:

@PrepareForTest({PriceCalculator.class, DiscountCategoryFinder.class})

Kao što je prikazano u gornjem primjeru, pretpostavimo da su i PriceCalculator i DiscountCategoryFinder konačne klase kojima se treba rugati. Obje se mogu spomenuti kao niz klasa u napomeni PrepareForTest i mogu se ugurati u testnoj metodi.

# 2) Pozicioniranje atributa PrepareForTest - Pozicioniranje ovog atributa važno je s obzirom na vrstu testova koji su uključeni u klasu Test.

Ako svi testovi trebaju koristiti istu završnu klasu, onda je smisleno spomenuti ovaj atribut na razini testne klase, što jednostavno znači da će pripremljena klasa biti dostupna svim testnim metodama. Suprotno tome, ako je napomena spomenuta na ispitnoj metodi, tada će biti dostupna samo tim određenim testovima

Zaključak

U ovom smo tutorijalu raspravljali o različitim pristupima ismijavanju statičkih, konačnih i praznih metoda.

Iako upotreba puno statičkih ili konačnih metoda ometa provjerljivost, ali ipak postoji podrška za testiranje / ruganje koja pomaže u stvaranju jediničnih testova kako bi se postiglo veće povjerenje u kod / aplikaciju čak i za naslijeđeni kôd koji se obično ne koristi za biti dizajniran za provjerljivost.

Za statičke i konačne metode Mockito nema gotovu podršku, ali knjižnice poput PowerMockita (koje puno toga nasljeđuju od Mockita) pružaju takvu podršku i moraju stvarno izvršiti manipulaciju bajt kodom kako bi podržale ove značajke.

Mockito out of the box podržava nabiranje praznih metoda i pruža razne metode poput doNothing, doAnswer, doThrow, doCallRealMethod itd. I može se koristiti prema zahtjevima testa.

Najčešće postavljana pitanja o intervjuu za Mockito ukratko su opisana u sljedećem vodiču.

PREV Vodič | SLJEDEĆA Vodič

Preporučena literatura

^