top 12 mockito interview questions
Най-често задаваните въпроси за интервю за Mockito за пробиване на подигравателното интервю за Mockito:
В предишния ни урок научихме Частни, статични и невалидни методи на подигравка . Прочетете пълни учебни уроци за Mockito за ясно разбиране на рамката на Mockito.
Тази статия обхваща най-често задаваните типични въпроси за интервюта в рамките на Mockito Mocking.
Очаква се всеки разработчик или QA да знае основите на Mocking, за да напише най-много тестове за бяла кутия (или модулни тестове) с лекота и да се подиграе на зависимостите за подобрено покритие на кода и по-голяма увереност в приложението.
Най-популярните въпроси за интервю с Mockito с подробни отговори
По-долу са изброени най-често задаваните въпроси относно Присмехулни рамки.
В # 1) Защо се нуждаем от подигравки?
Отговор: Има много случаи на подигравки, които помагат при единично тестване на изолирания код и правят теста силно повторяем и предсказуем.
Обикновено се подиграва, когато:
да се) Тестваният компонент има зависимости, които все още не са внедрени или внедряването е в ход.
Добър пример може да бъде крайна точка на REST API, която ще бъде достъпна по-късно в даден момент от времето, но сте я консумирали в кода чрез зависимост.
Сега, тъй като реалната имплементация все още не е налице, през повечето време наистина знаете какъв е очакваният отговор на този API. Подигравките ви позволяват да тествате тези видове интеграция.
б) Компонентът актуализира състоянието в системата.
Пример: DB разговори - не бихте искали да актуализирате вашата DB с данни, които са само за целите на тестването. Това може да доведе до повреждане на данните, освен това наличието на DB е друго предизвикателство при изпълнение на теста.
По този начин, за да се избегне подобно поведение, DB повикванията могат да бъдат подигравани в тествания компонент. Следователно няма пряко свързване на DB и тествания компонент.
В # 2) Разлика между doReturn и thenReturn.
Отговор: Mockito предоставя два различни синтаксиса за създаване на заглушки като:
- doReturn и след това Return
- не прави нищо (не тогава нищо)
- doThrow и послеThrow
И двата метода настройват заглушките и могат да се използват за създаване / настройване на заглушки и понякога могат да се използват взаимозаменяемо.
алгоритъм за сортиране на купчини c ++
И така, как се различават и двете?
да се) Начинът на блокиране thenReturn е безопасен начин за настройване на заглушители. Това, което по същество означава, е, че прави проверка по време на компилация спрямо типовете връщане, които също искате да заглушите.
Нека разберем това с пример:
Да приемем метод getItemDetails На mockedItemService който връща обект от тип ItemSku. Така че с след това Връщане, няма да можете да върнете нищо различно от тип ItemSku, но с doReturn можете да настроите заглушителя да връща каквото и да е, тестът ще се провали (или ще изведе изключение) по време на изпълнение.
// върши работа
when (mockedItemService.getItemDetails(123)).thenReturn(new ItemSku());
// хвърля изключение за времето на компилация
when (mockedItemService.getItemDetails(123)).thenReturn(expectedPrice);
// с doReturn и двете настройки на заглушителя работят, тъй като не са безопасни за компилиране.
// тук се опитваме да върнем обект от тип double, който все още работи и не извежда предупреждение за времето на компилация.
doReturn (expectedPrice).when(mockedItemService.getItemDetails(123)); doReturn (new ItemSku()).when(mockedItemService.getItemDetails(123));
б) Друга важна разлика между тези 2 начина за заглушаване е за Mocked обекти, освен безопасността при компилиране няма голяма разлика.
Обаче за шпионираните обекти настройката на тип заглушител „thenReturn“ няма да работи, тъй като ще доведе до извикване на реалния метод, преди зашеметяващият отговор да се върне като извикване и не на Mock, а на Spy, който обгръща реален екземпляр на обект .
Така че, предположим, има шпионин на име spiedObject и той има метод testMethod, който връща цяло число, след което за да настроите мъниче за това ще трябва да използвате doReturn вместо thenReturn.
doReturn (10).when(spiedObject.testMethod());
В # 3) Кога и защо трябва да се използва шпионин?
Отговор: Шпионинът е вид частичен макет, поддържан от Mockito.
Това по същество означава, че е тип екземпляр, където:
да се) Когато не се настройва макет, всяко взаимодействие с шпионин води до извикване на реалните методи. Но все пак ви позволява да проверите взаимодействията с шпионирания обект като - дали действително е бил извикан метод, колко пъти е бил извикан методът, какви са били аргументите, с които е бил извикан методът и т.н.
б) Дава ви гъвкавост за настройване на частични подигравки.
Например, ако имате обект с 2 метода - метод1 и метод2 и искате метод1 да бъде извикан и метод2 да бъде подиграван. Шпионите осигуряват такъв вид настройка.
И така, разликата между макет и мъниче с прости думи е - макетът се създава от тип, а не от екземпляр, докато мъничето обвива действителен екземпляр на обекта на класа.
В # 4) Защо статичните методи не могат да бъдат подигравани с Mockito?
кръгово свързан списък c ++
Отговор: Статичните методи са свързани със самия клас, а не с някакъв конкретен екземпляр на класа. Това означава, че всички екземпляри / обекти на класа използват един и същ екземпляр на статичния метод.
Статичните методи са по-скоро като процедурен код и се използват най-вече в старите системи като цяло.
Мокет библиотеките обикновено създават макети чрез динамично създаване на екземпляр по време на изпълнение, или чрез интерфейси, или чрез наследяване и тъй като статичният метод не е свързан с нито един конкретен екземпляр, не е възможно подигравателните рамки (като mockito, easy mock и т.н.) да се подиграват на статични методи.
Рамки като PowerMock, които имат поддръжка на статични методи, извършват манипулация на байт кода по време на изпълнение, за да се подиграват на статични методи.
В # 5) Каква е необходимостта да се провери дали извиканият макет е бил?
Отговор: Настройването на заглушител на подиграван обект (или шпиониран екземпляр) не гарантира дали изпъкналата настройка дори е била извикана.
Съвпадения за „проверка“, дайте възможност за валидиране дали в действителност е бил извикан създаденият заглушител или не, колко пъти е било осъществено повикването, с какви аргументи е бил извикан методът на заглушаването и т.н.
По същество това ни позволява да проверим настройката на теста и очаквания резултат по по-надежден начин.
В # 6) Какво е добър тестваем код?
Отговор:
Няколко точки относно тествания код (което означава, че лесно може да бъде тестван единично) включват:
- Намалено количество зависимости или здраво свързване - Пример: Зависимостите трябва да се инжектират, а не да се инстанцират директно.
- Код, който се придържа към SRP (Принцип на единна отговорност) - Това по същество означава, че класът не трябва да има множество причини за промяна. Придържането към SRP избягва класовете, създаващи зависимост от себе си и поддържа кода сплотен и чист.
- По-малко / минимално използване на статични методи и крайни класове - Те обикновено показват миризми на кода и са свързани най-вече със стария код.
В # 7) Какви са ограниченията на Mockito?
Отговор: Mockito е избрана рамка за повечето проекти, базирани на java. Той е лесен за изпълнение, четене и разбиране.
Някои от недостатъците или ограниченията по отношение на функционалността са:
- Неспособността му да се подиграва на статични методи.
- Конструктори, частни методи и финални класове не могат да бъдат подигравани.
В # 8) Кои рамки могат да поддържат подигравки с частни и статични методи?
Отговор: Рамки като PowerMockito (разширения на Mockito framework), JMockit и др. Предоставят средства за подигравка на частни и статични методи.
В # 9) Подигравки / забиване на методи по подразбиране в Интерфейс в Java 8.
Отговор: С внедряването на Java 8 на методите по подразбиране в интерфейса, Mockito предоставя незабавна поддръжка, за да се подиграва на такива методи по подразбиране. (Моля, обърнете внимание, че тази поддръжка е въведена от Mockito 2 нататък).
Тези методи могат да бъдат подигравани / смачкани като всички други методи на клас или интерфейс.
В # 10) Как може да се провери редът на извикванията на заглушителите в Mockito?
Отговор: Когато искате да проверите реда, в който са били извиквани подигравки, „Mockito’s“ InOrder ”Може да се използва интерфейс.
По време на теста просто трябва да настроите / създадете обект Inorder, като изброите списък с макетни обекти, в които трябва да се установи реда на макетите (ако има няколко метода в един макет и няма друг макет, който се нуждае за да бъде проверено тогава е достатъчно да се спомене подигравания клас само веднъж).
Помислете за теста, даден по-долу, който дефинира обект на InOrder и споменава 2 случая на 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()); }
Също така, за справка, изброяването на кода на тествания метод ще бъде полезно за разбиране на реда на изпълнение на теста:
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); }
Както се вижда по-горе, databaseImpl първо извиква updateScores и след това извиква getGrade.
Така че, ако пишете единичен тест с помощта на Mockito, за това и трябва да осигурите реда на извикванията на databaseImpl, обърнете се към тестовия код и се уверете, че твърденията са направени според очаквания ред.
кой е най-добрият софтуер за копиране на DVD
В горния пример, ако променя реда на твърдения, това ще доведе до неуспех на теста с изключение на „VerificationInOrderFailure“.
След промяна на реда за заявяване кодът изглежда както е показано по-долу:
@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()); }
Горното изпълнение на теста хвърля изключение с тип:
“VerificationInOrderFailure” org.mockito.exceptions.verification.VerificationInOrderFailure:
Проверка за грешка на поръчката
Търси се, но не се извиква:
mockDatabaseImpl.updateScores (
isA (java.lang.String),
isA (java.lang.Integer)
В # 11) Връщане на множество стойности срещу последователни извиквания на методи
Отговор: За да върне различни стойности за множество извиквания на един и същ метод, Mockito предоставя 3 подхода, както е дадено по-долу:
да се) Използване на разделени със запетая: Това работи с thenReturn.
Например , като вземем горната проба на кода, нека се опитаме да настроим последователен мъниче за метод - getGrade, който ще върне различни стойности в зависимост от последователността от итерации:
when (mockDatabaseImpl.getGrade( anyInt ())).thenReturn('A','B', 'C');
Това означава, че когато методите getGrade бъдат извикани в тествания метод, първото извикване ще върне „A“, второто извикване ще върне „B“ и т.н.
б) Последователно след това Връщане: Това е подход, който е обвързан с инструкции thenReturn. Прилагането на верижни повиквания към същия пример ще изглежда както е показано по-долу.
when (mockDatabaseImpl.getGrade( anyInt ())).thenReturn('A').thenReturn('B').thenReturn('C');
в) Последователно връщане: Последният подход е използването на doReturn във верижен формат, както по-горе.
doReturn ('A').doReturn('B').doReturn('C').when(mockDatabaseImpl).getGrade( anyInt ())
В # 12) Какви са различните видове подигравателни рамки и как работят?
Отговор: Видовете рамка за подигравки и как работят те са обяснени по-долу.
Има общо 2 категории подигравателни рамки:
- Прокси базирана - Пример, Mockito, EasyMock и др.
- Въз основа на байт код - Пример, PowerMock, JMockit и др.
Нека сравним двете рамки по различни параметри.
Прокси базиран | Въз основа на байт код | |
---|---|---|
Опростено | По-лесни и лесни за използване | Може да включва сложна фиктивна логика за настройка |
Начин на създаване | Създава се прокси или фалшив обект, който всъщност не изисква екземпляр на клас / интерфейс | По същество включва създаване на обекти и по време на изпълнение манипулира екземплярите за подиграваното / потъналото поведение |
Функционалност | Подигравателни класове и интерфейси | В допълнение към класовете и интерфейсите, позволява подигравателни статични методи, крайни класове и т.н. |
Зависимост от Java | Не е много тясно свързан с java версии | Тъй като тези рамки включват манипулиране на байт кодове, те са тясно свързани и може да не са съвместими назад / напред във версиите на java. |
Примери | Mockito, EasyMock и др. | PowerMock, JMockit и др. |
Заключение
Съдържанието, обхванато в тази статия, служи за основни дискусии около подигравателните рамки и по-специално подготовката за интервю за Mockito.
В допълнение към теоретичното разбиране на разгледаните въпроси, трябва да се опитате да направите и реални примери за код, което прави изучаването на тези рамки по-забавно и интересно.
Надявам се, че сте се насладили на цялата гама от уроци в тази серия Mockito.
Честито обучение.
Препоръчително четене
- Интервюирайте въпроси и отговори
- Mockito Tutorial: Mockito Framework for Mocking in Unit Testing
- Някои интересни въпроси за интервю за тестване на софтуер
- Въпроси и отговори за интервю за ETL тестване
- Водещи въпроси за интервюта за формуляри и доклади на Oracle
- Софтуерно ръчно тестване Интервю въпроси за опитни професионалисти
- Най-добрите технически въпроси за Oracle Apps и интервюта за Oracle SOA
- 25 най-добри пъргави тестови интервюта Въпроси и отговори