Menu

12 najčastejších otázok týkajúcich sa rozhovorov (modelový rozhovor)

  • Hlavná
  • Iné
  • 12 najčastejších otázok týkajúcich sa rozhovorov (modelový rozhovor)

top 12 mockito interview questions

Vyskúšajte Náš Nástroj Na Odstránenie Problémov

Najčastejšie otázky týkajúce sa rozhovoru s Mockitom, ktoré sa majú rozlúsknuť The Mockito Mocking Interview:

V našom predchádzajúcom tutoriáli sme sa dozvedeli Súkromné, statické a neplatné metódy zosmiešňovania . Prečítajte si kompletné školiace návody na Mockito pre jasné pochopenie rámca Mockito.

Tento článok sa venuje najčastejšie kladeným typickým otázkam pri rozhovoroch týkajúcich sa rámca Mockito Mocking.

Očakáva sa, že každý vývojár alebo QA pozná základy posmievania, aby mohol s ľahkosťou písať najbežnejšie testy (alebo testy jednotiek) a zosmiešňovať závislosti pre lepšie pokrytie kódom a väčšiu dôveru v aplikáciu.

Mockito, otázky z rozhovoru

Najobľúbenejšie otázky týkajúce sa rozhovorov s podrobnými odpoveďami

Nižšie sú uvedené najbežnejšie otázky týkajúce sa vysmievacích rámcov.

Otázka č. 1) Prečo sa potrebujeme posmievať?

Odpoveď: Existuje veľa prípadov použitia výsmechu, ktoré pomáhajú pri jednotkovom testovaní izolovaného kódu a robia test vysoko opakovateľným a predvídateľným.

Vysmievanie sa zvyčajne vyžaduje, ak:

do) Testovaný komponent má závislosti, ktoré ešte nie sú implementované alebo implementácia práve prebieha.

Dobrým príkladom môže byť koncový bod REST API, ktorý bude k dispozícii neskôr v určitom okamihu, ale spotrebovali ste ho v kóde prostredníctvom závislosti.

Pretože skutočná implementácia stále nie je k dispozícii, naozaj väčšinou viete, aká je očakávaná odozva daného API. Vysmievanie umožňuje testovať tieto druhy integrácie.

b) Komponent aktualizuje stav v systéme.

Príklad: Hovory DB - nechcete, aby sa vaša DB aktualizovala údajmi, ktoré slúžia iba na testovacie účely. To by mohlo mať za následok poškodenie údajov, navyše dostupnosť DB je ďalšou výzvou pri vykonávaní testu.

Preto, aby sa zabránilo takémuto správaniu, sa môžu hovory DB vysmievať v testovanej súčasti. Preto neexistuje priame spojenie DB a testovaného komponentu.

Otázka 2) Rozdiel medzi doReturn a thenReturn.

Odpoveď: Mockito poskytuje dve rôzne syntaxe pre vytváranie stubov, ako napríklad:

  • doReturn a potomReturn
  • nerob nič (nie potom nič)
  • doThrow a thenThrow

Obe tieto metódy nastavujú pahýly a dajú sa použiť na vytvorenie / nastavenie pahýľov a dajú sa občas použiť zameniteľné.

najlepšia bezplatná služba konferenčných hovorov do roku 2020

V čom sa teda obidve líšia?

do) Spôsob pahýľu thenReturn je typovo bezpečný spôsob nastavenia pahýľov. To v podstate znamená, že vykonáva kontrolu kompilácie proti návratovým typom, ktoré chcete tiež zameniť.

Poďme to pochopiť na príklade:

Predpokladajme metódu getItemDetails na mockedItemService ktorý vráti objekt typu ItemSku. Takže s potom návrat, nebudete môcť vrátiť nič iné ako typu ItemSku, ale pomocou doReturn môžete nastaviť útržok, ktorý vráti čokoľvek, a test zlyhá (alebo vyvolá výnimku) počas vykonávania.

// Tvorba

when (mockedItemService.getItemDetails(123)).thenReturn(new ItemSku());

// hodí výnimku času kompilácie

when (mockedItemService.getItemDetails(123)).thenReturn(expectedPrice);

// s doReturn, obe nastavenia stubu fungujú, pretože to nie je bezpečné.

// tu sa snažíme vrátiť objekt typu double, ktorý stále funguje a nevyvoláva žiadne upozornenie na kompiláciu.

doReturn (expectedPrice).when(mockedItemService.getItemDetails(123)); doReturn (new ItemSku()).when(mockedItemService.getItemDetails(123));

b) Ďalším dôležitým rozdielom medzi týmito 2 spôsobmi útržku sú Mocked objekty, okrem bezpečnosti zostavenia nie je veľký rozdiel.

Avšak pre špionážne objekty nebude nastavenie „stub“ „thenReturn“ fungovať, pretože bude mať za následok volanie skutočnej metódy skôr, ako sa stubbed odpoveď vráti ako hovor, a nie na Mock, ale na Spy, ktorý zahaľuje inštanciu skutočného objektu .

Predpokladajme teda, že existuje nejaký špión spiedObject a má metódu testMethod, ktorá vracia celé číslo, potom na nastavenie pahýľa budete musieť použiť doReturn namiesto thenReturn.

doReturn (10).when(spiedObject.testMethod());

Otázka č. 3) Kedy a prečo by sa mal použiť špión?

Odpoveď: Spy je druh čiastočnej falošnej hry, ktorú podporuje Mockito.

V podstate to znamená typ inštancie, kde:

do) Ak nie je nastavený žiadny falošný pokus, výsledkom akejkoľvek interakcie so špiónom sú skutočné metódy. Ale stále vám umožňuje overiť interakcie so špionážnym objektom, napríklad - bola metóda skutočne volaná, koľkokrát bola metóda volaná, aké boli argumenty, pomocou ktorých bola metóda volaná atď.

b) Poskytuje vám flexibilitu pri nastavovaní čiastočných falošných správ.

Napríklad, ak máte objekt s 2 metódami - method1 a method2 a chcete, aby sa volala metóda1 a metóda2 sa vysmievala. Spies poskytujú tento druh nastavenia.

Rozdiel medzi falošným a stubom je teda jednoduchý - falošný je vytvorený z typu a nie z inštancie, zatiaľ čo stub obaľuje skutočnú inštanciu objektu triedy.

Otázka č. 4) Prečo sa pomocou Mockita nedajú zosmiešniť statické metódy?

nedefinovaný odkaz na funkciu c ++

Odpoveď: Statické metódy sú spojené s triedou samotnou, a nie s konkrétnou inštanciou triedy. To znamená, že všetky inštancie / objekty triedy používajú rovnakú inštanciu statickej metódy.

Statické metódy pripomínajú skôr procedurálny kód a používajú sa väčšinou v starších systémoch všeobecne.

Falošné knižnice zvyčajne vytvárajú zosmiešňovanie dynamickým vytváraním inštancií za behu, a to buď prostredníctvom rozhraní, alebo prostredníctvom dedenia. Pretože statická metóda nie je spojená s konkrétnou inštanciou, nie je možné zosmiešňovať statické metódy zosmiešňovaním rámcov (napr. Zosmiešňovanie, ľahké zosmiešňovanie atď.).

Rámec ako PowerMock, ktorý podporuje statické metódy, vykonáva manipuláciu s bytecode za behu, aby zosmiešňoval statické metódy.

Otázka č. 5) Čo je potrebné na overenie toho, či bol falošný volaný?

Odpoveď: Nastavenie stubu na zosmiešnenom objekte (alebo špehovanej inštancii) nezaručuje, či bolo stubbed nastavenie dokonca vyvolané.

Porovnávače „overenia“, dajte zariadeniu na overenie, či bol nastavený stub skutočne vyvolaný alebo nie, koľkokrát bol hovor uskutočnený, s akými argumentmi sa volala stubbed metóda atď.

V zásade nám umožňuje overiť nastavenie testu a očakávaný výsledok robustnejším spôsobom.

Otázka 6) Čo je to dobre testovateľný kód?

Odpoveď:

Niekoľko bodov o testovateľnom kóde (čo znamená, že by sa dal ľahko otestovať na jednotku) obsahuje:

  • Znížená závislosť alebo tesné spojenie - Príklad: Závislosti by sa mali vkladať skôr ako priame inštancie.
  • Kód, ktorý dodržiava SRP (princíp jednej zodpovednosti) - To v podstate znamená, že trieda by nemala mať viac dôvodov na zmenu. Dodržiavanie pravidiel SRP sa vyhýba tomu, aby triedy vytvorili závislosť od seba, a udržiava kód súdržný a čistý.
  • Menej / minimálne použitie statických metód a záverečných kurzov - Tieto vo všeobecnosti naznačujú vône kódu a boli väčšinou spojené so starým kódom.

Otázka č. 7) Aké sú obmedzenia Mockita?

Odpoveď: Mockito je rámcom voľby pre väčšinu projektov založených na jave. Je ľahké ho implementovať, čítať a porozumieť mu.

Niektoré z nevýhod alebo obmedzení z hľadiska funkčnosti sú:

  • Jeho neschopnosť simulovať statické metódy.
  • Konštruktérom, súkromným metódam a záverečným kurzom sa nemožno vysmievať.

Otázka 8) Ktoré rámce môžu podporovať zosmiešňovanie súkromných a statických metód?

Odpoveď: Rámec ako PowerMockito (rozšírenie rámca Mockito), JMockit atď. Poskytuje prostriedky na zosmiešňovanie súkromných a statických metód.

Q # 9) Vysmievanie sa a stubbing štandardných metód v rozhraní v Jave 8.

Odpoveď: S implementáciou predvolených metód v rozhraní Java 8 v rozhraní Mockito poskytuje okamžitú podporu pre zosmiešňovanie týchto predvolených metód. (Upozorňujeme, že táto podpora bola zavedená od verzie Mockito 2).

Tieto metódy môžu byť zosmiešňované / tvrdené ako akékoľvek iné metódy triedy alebo rozhrania.

Otázka č. 10) Ako je možné v Mockite overiť poradie vyvolaných odkazov?

Odpoveď: Ak chcete overiť poradie, v akom boli volané falošné správy, Mockitovo „ InOrder “Možno použiť rozhranie.

Počas testu musíte jednoducho nastaviť / vytvoriť objekt Inorder a vypísať zoznam falošných objektov, u ktorých je potrebné zistiť poradie falošných správ (ak existuje viac metód na rovnakom falošnom teste a neexistuje žiadny iný falošný program, ktorý by potreboval) na overenie potom stačí spomenúť posmešnú triedu iba raz).

Zvážte test uvedený nižšie, ktorý definuje objekt InOrder a uvádza 2 výskyty mockDatabaseImpl.

@Test public void calculateSumAndStore_withValidInput_verifyMockOrder() { // Arrange studentScores = new StudentScoreUpdates(mockDatabaseImpl); int() scores = {60,70,90}; Mockito.doNothing().when(mockDatabaseImpl).updateScores(anyString(), anyInt()); Mockito.doReturn('A').when(mockDatabaseImpl).getGrade(anyInt()); InOrder inorder = inOrder(mockDatabaseImpl); // Act studentScores.calculateSumAndStore('Student1', scores); // Assert inorder.verify(mockDatabaseImpl).updateScores(anyString(),anyInt()); inorder.verify(mockDatabaseImpl).getGrade(anyInt()); }

Ďalej uvádzame zoznam kódov testovaných metód, aby ste pochopili poradie vykonania testu:

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); databaseImpl.getGrade(total); }

Ako je vidieť vyššie, databaseImpl najskôr zavolá updateScores a potom zavolá getGrade.

Pokiaľ teda píšete jednotkový test pomocou nástroja Mockito, musíte pre tento účel zabezpečiť poradie volaní na databaseImpl, pozrite si testovací kód a zabezpečte, aby sa tvrdenia uskutočňovali podľa očakávaného poradia.

Ak vo vyššie uvedenom príklade zmením poradie tvrdení, spôsobí to zlyhanie testu s výnimkou „VerificationInOrderFailure“.

rozdiel medzi funkčným a nefunkčným testovaním

Po zmene objednávky bude kód vyzerať takto:

@Test public void calculateSumAndStore_withValidInput_verifyMockOrder() { // Arrange studentScores = new StudentScoreUpdates(mockDatabaseImpl); int() scores = {60,70,90}; Mockito.doNothing().when(mockDatabaseImpl).updateScores(anyString(), anyInt()); Mockito.doReturn('A').when(mockDatabaseImpl).getGrade(anyInt()); InOrder inorder = inOrder(mockDatabaseImpl); // Act studentScores.calculateSumAndStore('Student1', scores); // Assert inorder.verify(mockDatabaseImpl).updateScores(anyString(),anyInt()); inorder.verify(mockDatabaseImpl).getGrade(anyInt()); }

Vyššie uvedené vykonanie testu vyvolá výnimku s typom:

„VerificationInOrderFailure“ org.mockito.exceptions.verification.VerificationInOrderFailure:
Overenie zlyhania objednávky
Chcel, ale nebol vyvolaný:
mockDatabaseImpl.updateScores (
isA (java.lang.String),
isA (java.lang.Integer)

Otázka č. 11) Vrátenie viacerých hodnôt proti po sebe idúcim volaním metód

Odpoveď: Ak chcete vrátiť rôzne hodnoty pre viacnásobné vyvolanie rovnakej stubbed metódy, Mockito poskytuje 3 prístupy, ako je uvedené nižšie:

do) Oddelené čiarkou: Toto funguje s parametrom thenReturn.

Napríklad , vezmeme si vyššie uvedenú ukážku kódu, skúsme teda nastaviť postupný stub pre metódu - getGrade, ktorá vráti rôzne hodnoty v závislosti od postupnosti iterácií:

when (mockDatabaseImpl.getGrade( anyInt ())).thenReturn('A','B', 'C');

To znamená, že keď sa v testovanej metóde vyvolajú metódy getGrade, prvé vyvolanie vráti „A“, druhé vyvolanie „B“ atď.

b) Postupné potom Návrat: Toto je prístup, ktorý je spojený s príkazmi thenReturn. Aplikácia zreťazených hovorov na rovnaký príklad bude vyzerať nasledovne.

when (mockDatabaseImpl.getGrade( anyInt ())).thenReturn('A').thenReturn('B').thenReturn('C');

c) Postupný návrat Posledným prístupom je použitie doReturn v zreťazenom formáte, ako je uvedené vyššie.

doReturn ('A').doReturn('B').doReturn('C').when(mockDatabaseImpl).getGrade( anyInt ())

Otázka č. 12) Aké sú rôzne typy zosmiešňujúcich rámcov a ako fungujú?

Odpoveď: Ďalej sú vysvetlené typy rámca Mocking a spôsob ich fungovania.

Existujú celkovo 2 kategórie zosmiešňujúcich rámcov:

  1. Na základe proxy servera - Príklad, Mockito, EasyMock atď.
  2. Bytecode založené - Príklad, PowerMock, JMockit atď.

Porovnajme obidva tieto rámce s rôznymi parametrami.

Na základe proxy serveraBytecode založené
ZjednodušeneJednoduchšie a ľahšie použiteľnéMôže to zahŕňať zložitú falošnú logiku nastavenia
Spôsob tvorbyVytvorí sa proxy alebo falošný objekt, ktorý v skutočnosti nevyžaduje inštanciu triedy / rozhraniaV podstate to zahŕňa vytváranie objektov a za behu manipuluje s inštanciami zosmiešňovaného / znevažovaného správania
FunkčnosťPosmešné triedy a rozhraniaOkrem tried a rozhraní umožňuje posmievanie sa statickým metódam, záverečným kurzom atď
Závislosť JavaNie veľmi úzko prepojené s verziami JavaPretože tieto rámce zahŕňajú manipuláciu s bytecode, sú pevne spojené a nemusia byť spätne / vpred kompatibilné vo všetkých verziách Java.
PríkladyMockito, EasyMock atď.PowerMock, JMockit atď.

Záver

Obsah uvedený v tomto článku slúži na základné diskusie o rámcoch Mocking a konkrétne o príprave rozhovorov Mockito.

Okrem teoretického porozumenia preberaných otázok by ste sa mali pokúsiť vyskúšať príklady skutočných kódov, vďaka ktorým je učenie týchto rámcov zábavnejšie a zaujímavejšie.

Dúfam, že sa vám páčila celá škála návodov v tejto sérii Mockito.

Šťastné učenie.

Výukový program PREV | PRVÝ výukový program

Odporúčané čítanie

^