mockito tutorial mockito framework
Пълно ръководство за Mockito Framework: практически ръководства за Mockito
най-добрият софтуер за скриване на ip адрес
Единичното тестване е проста, но ефективна техника за постигане на добро ниво на доверие в кода, който трябва да бъде изпратен.
Освен това избягва проблеми с регресията с всеки код, който се чекира.
С архитектура от тип микро услуги (и дори за проста структура, включваща основни повиквания към база данни), простото тестване на модули не е достатъчно. Това, от което се нуждаем, е да се подиграем на зависимостите и да тестваме действителната логика на тествания метод.
Списък на ВСИЧКИ уроци по Mockito в тази поредица:
Урок # 1: Mockito Framework за подигравки при единично тестване (Този урок)
Урок # 2: Създаване на макети и шпиони в Mockito
Урок № 3: Различни видове съвпадения, предоставени от Mockito
Урок № 4: Подигравка на частни, статични и невалидни методи с помощта на Mockito
Урок № 5: Топ 12 въпроса за интервю за Mockito
************************************************* * *******************
Преглед на уроци в тази серия Mockito
Урок # | Какво ще научите |
---|---|
Урок # 1: | Mockito Framework за подигравки при единично тестване Научете се подигравате с Mockito - изчерпателен урок за Mockito за начинаещи с примери за кодове. Научете Mocking Framework за подигравки при тестване на единици. |
Урок # 2: | Създаване на макети и шпиони в Mockito Подигравки и шпиони са видове тестови двойки, които са полезни при писането на модулни тестове. И двете са обяснени в този урок за Mockito Spy с примери за код. |
Урок № 3: | Различни видове съвпадения, предоставени от Mockito Научете как да използвате различни видове съвпадения, предоставени от Mockito. Съвпаденията са като заместващи символи, където вместо конкретен вход / изход, вие посочвате диапазон на въвеждане. Аргумент и Проверка са двата вида Съвпадения в Mockito, които са обяснени подробно тук. |
Урок № 4: | Подигравка на частни, статични и невалидни методи с помощта на Mockito Научете подигравателни методи Private, Static и Void в Mockito с примери. Научете подигравателни частни и статични методи чрез модулна тестова рамка PowerMockito. |
Урок № 5: | Топ 12 въпроса за интервю за Mockito Въпроси и отговори за интервю за Mockito с примерни примери за кодове. Това ще ви помогне да пробиете успешно всяко интервю за Mockito Mocking Framework. |
Нека започнем с първия урок от тази поредица !!
Какво ще научите:
- Подигравка при тестване на единици
- Видове / категории тестови двойки
- Различни подигравателни рамки
- Програмен код
- Заключение
- Препоръчително четене
Подигравка при тестване на единици
Mocks / Stubs е термин, който хората често чуват, докато създават по-специално модулни тестове.
И така, какво по същество е подигравка? По-просто казано, това е нищо друго освен предоставяне на контролиран екземпляр или изпълнение на зависимост, от която зависи тестваният код, за да се тества неговата основна логика.
Причината, поради която го споменах като контролиран екземпляр, е, че поведението на зависимостта може да бъде програмирано или контролирано по желание за тествания метод или система.
За да го обясним схематично, нека вземем пример за всяко приложение за бизнес или електронна търговия. Почти всеки такъв тип приложение има предимно 3 слоя, т.е. Потребителски интерфейс, бизнес слой и слой за достъп до данни (което говори с основното хранилище на данни)
Позовавайки се на горната диаграма, бизнес слой има 3 зависимости, а именно, т.е. слой за достъп до данни и 2 други услуги, които са услуга 1 и услуга 2.
Погледнете по този начин - Приложение като google maps може да има зависимости от
- Действителни хранилища на данни като MySQL или всяка друга база данни без SQL, която съхранява данни от карта.
- Външна услуга като CoordinateService, която предоставя географски ширини и дължини на дадено местоположение.
- Външна услуга като услуга за трафик, която предоставя информация за трафика в реално време за дадена двойка координати.
Така че, ако някой се опитва да провери основната бизнес логика с помощта на единичен тест, докато и освен ако няма работещи имплементации на тези зависимости, тестовете не могат да бъдат изпълнени.
Подигравки идват на помощ в тези ситуации, когато независимо дали зависимостта ви работи и не работи, вие винаги сте гарантирани, че ще изпълнявате бизнес логиката си с програмиран отговор за зависимостта, която се извиква от тествания код.
Видове / категории тестови двойки
Mock по същество е тип „Test Double“ - това е технологичен жаргон. „Тест двойно“ по същество означава обект, който е заменен от еквивалентен реален екземпляр на обект или зависимост.
Има различни видове тестови двойки, както е посочено по-долу:
# 1) Фалшификати:
Фалшификатът е работеща реализация, подобна на реална зависимост, с изключение на факта, че е локална за тестваната система.
Пример: Вместо да удари реална производствена база данни, тестът използва проста колекция / в паметта за съхраняване на данни.
# 2) Stubs:
Stubs са предварително конфигурирани отговори, когато се извиква зависимост от тестваната система.
# 3) Шпиони:
Както подсказва името, всъщност реалната му функция (зависимост) се обажда с някакъв механизъм за наблюдение. Публикувайте обаждането, може да се провери дали разговорът всъщност е бил задействан или не, заедно с параметрите.
# 4) Подигравки:
Подигравките са специални екземпляри на обекти, върху които могат да бъдат посочени Stubbed / предварително конфигурирани отговори. Фактът, че макетът е извикан, може да бъде проверен като твърдение в теста.
Например:
Има функция за генериране на отчети, която изпраща имейл на определен адрес по време на изпълнение.
Тъй като не искаме да изпращаме действителен имейл, отново и отново, по време на тестване, EmailService се подиграва (а методът на имейл, който изпраща имейла, е конфигуриран да не прави нищо, когато е извикан). В края на теста можем просто да проверим дали методът за изпращане на имейли на имейл услугата е извикан през подигравания обект.
Различни подигравателни рамки
Почти всички езици предоставят различни видове подигравателни рамки. Ще пишем примерен код, използвайки Mockito, който е Mocking framework с отворен код за Java.
Анатомия на прост единичен тест с присмехулна зависимост. Да предположим, че се опитваме да тестваме модулно приложение, което изчислява общите оценки за студент по всички предмети и го записва в DB.
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); }
Сега, ако искаме да напишем единичен тест за метода - CalcuSumAndStore, тогава може да нямаме реално внедряване на база данни за съхраняване на общото. В този случай никога няма да можем да тестваме единица тази функция.
Но с мокети на място, можем просто да предадем Mock за услуга на база данни и да проверим останалата част от логиката
Примерен тест, както е показано по-долу:
@Test public void calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb() { // Arrange studentScores = new StudentScoreUpdates(mockDatabase); int() scores = { 60, 70, 90 }; Mockito.doNothing().when(mockDatabase).updateScores('student1', 220); // Act studentScores.calculateSumAndStore('student1', scores); // Assert Mockito.verify(mockDatabase, Mockito.times(1)).updateScores('student1', 220); }
Видяхме в горния тест, предоставихме обект mockDatabase на родителския клас (за метода, който се тества) и сме настроили отговор на заглушаване на обекта mockedDatabase - ред # 6 по-горе (Mockito.doNothing (). Когато (mockDatabase) .updateScores (“student1”, 220);)
Важните моменти, които трябва да се отбележат от горното, са:
# 1) Подиграваният обект трябва да настрои скрити отговори за всички методи, които ще бъдат извикани по време на изпълнението на функцията.
# две) Параметрите, посочени по време на създаването на мъниче, могат да бъдат специфични или общи.
Пример в горния случай - посочихме параметрите за метода updateScores като “student1” и 220, защото знаем, че това са точните входове, с които ще бъде извикан нашият метод.
# 3) По време на проверката проверяваме следното:
- Извикан беше методът mockDatabase.updateScores.
- Аргументите бяха съответно „студент1“ и 220.
- Методът updateScores беше извикан 1 път.
Сега нека опитаме да променим малко този тестов код и да видим какво ще стане:
Ще променя аргумента в мокет настройката от “student1” на anyString (Mockito осигурява стандартен съвпадение на име anyString ()) & 220 на anyInteger (Mockito предлага стандартен съвпадение на име anyInt () и той съответства на всяка цяло число)
@Test 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('student1', 220); }
Опитайте да стартирате теста отново и той все още трябва да е зелен.
(Нека сега опитаме да променим проверката / твърдения и да променим някой от аргументите.
Нека променим 220 на 230. Сега очакването е, че тестът трябва да се провали, тъй като това не е очакваният аргумент, с който трябва да е извикан dataUpdate.
@Test 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('student1', 230); }
След стартиране на теста се обърнете към регистрационните файлове за грешки, както е показано по-долу (там ясно се споменава, че действителните аргументи не съвпадат с очакваните).
Аргументите са различни! Търси се:
mockDatabase.updateScores (“student1”, 230);
-> на com.mocking.sampleMocks.StudentScoreUpdatesUnitTests.calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb (StudentScoreUpdatesUnitTests.java:37)
Действителното извикване има различни аргументи:
mockDatabase.updateScores („студент1“, 220);
Програмен код
Интерфейс - IDatabase.java
public interface IDatabase { public void updateScores(String studentId, int total); }
Тестван клас - StudentScoreUpdates.java
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); } }
Клас на единични тестове - StudentScoreUpdatesUnitTests.java
public class StudentScoreUpdatesUnitTests { @Mock public IDatabase mockDatabase; public StudentScoreUpdates studentScores; @BeforeEach public void beforeEach() { MockitoAnnotations.initMocks(this); } @Test 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('student1', 230); } }
Заключение
Това, което видяхме досега, е много основен и ясен пример за настройка на Mock с помощта на Java Mockito framework.
За почти 60-70% от единичните тестове, включващи макети, тестовете трябва да имат подобна структура. Mockito предоставя много усъвършенствана конфигурация / поддръжка за обширни подигравателни нужди, инжектирайки фиктивни екземпляри, използвайки инжекция на зависимост, осигурява шпиони, които действително да шпионират реално извикване на метод и да проверяват повикванията.
Предстоящият ни урок ще обясни повече за концепцията за подигравки и шпиони в Mockito.
Препоръчително четене
- Топ 12 въпроса за интервю за Mockito (подигравателно рамково интервю)
- Уроци за задълбочено затъмнение за начинаещи
- Как да настроите рамката за тестване на Node.js: Урок за Node.js
- Писане на единични тестове със Spock Framework
- Разликите между модулното тестване, интегрираното тестване и функционалното тестване
- Най-добри инструменти за тестване на софтуер 2021 г. (Инструменти за автоматизация на QA теста)
- Урок за деструктивно изпитване и безразрушително тестване
- Функционално тестване срещу нефункционално тестване