Меню

Підручник Mockito: Mockito Framework для знущань під час модульного тестування

  • Головна
  • Інший
  • Підручник Mockito: Mockito Framework для знущань під час модульного тестування

mockito tutorial mockito framework

Спробуйте Наш Інструмент Для Усунення Проблем

Повний посібник з Mockito Framework: практичні підручники з Mockito

хто відповідає за цінність бізнесу, яку надає команда сутичок?

Модульне тестування - це проста, але ефективна техніка, щоб отримати хороший рівень довіри до коду, який має бути відправлений.

Більше того, це дозволяє уникнути проблем регресії з кожним фрагментом коду, який реєструється.

З архітектурою мікросервісів (і навіть для простої структури, що включає базові виклики до бази даних), простого модульного тестування недостатньо. Нам потрібно знущатися над залежностями та перевіряти фактичну логіку тестованого методу.

Підручник з Mockito

Список ВСІХ підручників з Mockito у цій серії:

Підручник No1: Mockito Framework для знущань при модульному тестуванні (Цей підручник)
Підручник No2: Створення насмішок і шпигунів в Mockito
Підручник No3: Різні типи збігів, надані Mockito
Підручник No4: Знущання над приватними, статичними та недійсними методами за допомогою Mockito
Підручник No5: Найпопулярніші 12 запитань інтерв’ю Mockito

************************************************* * *******************

Огляд підручників у цій серії Mockito

Підручник №Що ви дізнаєтесь
Підручник No1: Mockito Framework для знущань при модульному тестуванні

Навчіться глузувати з Mockito - Вичерпний підручник Mockito для початківців із прикладами коду. Дізнайтеся, як висміювати основи для знущань під час модульного тестування.
Підручник No2: Створення насмішок і шпигунів в Mockito

Знущання та шпигуни - це різновиди тестових дублів, які корисні при написанні модульних тестів. І те, і інше пояснюється в цьому посібнику Mockito Spy із прикладами коду.
Підручник No3: Різні типи збігів, надані Mockito

Дізнайтеся, як користуватися різними типами збігів, що надаються Mockito. Збіги схожі на символи підстановки, де замість конкретного вводу / виводу ви вказуєте діапазон введення. Аргумент та перевірка - це два типи збігів у Mockito, які докладно пояснюються тут.
Підручник No4: Знущання над приватними, статичними та недійсними методами за допомогою Mockito

Вивчіть знущання над методами Private, Static та Void у Mockito на прикладах. Вивчіть знущання над приватними та статичними методами за допомогою модульного модульного тестування PowerMockito.
Підручник No5: Найпопулярніші 12 запитань інтерв’ю Mockito

Запитання та відповіді на інтерв’ю Mockito із зразками прикладів коду. Це допоможе вам успішно зламати будь-яке інтерв’ю Mockito Mocking Framework.

Почнемо з першого підручника з цієї серії !!

Що ви дізнаєтесь:

Знущання при модульному тестуванні

Знущання / заглушки - це термін, який люди зазвичай чують, зокрема створюючи модульні тести.

Отже, що по суті таке насмішка? Простіше кажучи, це не що інше, як забезпечення контрольованого екземпляра або реалізація залежності, від яких залежить тестований код, щоб перевірити його основну логіку.

Причиною того, що я згадав це як контрольований примірник, є те, що поведінку залежності можна запрограмувати або контролювати, як бажано для методу або системи, що перевіряється.

Щоб схематично це пояснити, візьмемо приклад будь-якого додатка для бізнесу чи електронної комерції. Майже кожен такий тип нанесення має переважно 3 шари, тобто Інтерфейс користувача, рівень бізнесу та рівень доступу до даних (який розмовляє з базовим сховищем даних)

Приклад: Залежності UnitTesting

Посилаючись на наведену вище діаграму, Business Layer має 3 залежності, а саме: рівень доступу до даних та 2 інші служби, які є Service 1 і Service 2.

Подивіться на це так - така програма, як google maps, може мати залежність від

  1. Фактичні сховища даних, такі як MySQL або будь-яка інша база даних SQL, яка не зберігає дані карти.
  2. Зовнішня служба, така як CoordinateService, яка надає широти та довготу місцезнаходження.
  3. Зовнішня служба, подібна службі руху, яка надає інформацію про дорожній рух у режимі реального часу для даної пари координат.

Отже, якщо хтось намагається перевірити основну бізнес-логіку за допомогою модульного тестування, доки і якщо у них немає робочих реалізацій цих залежностей, тести неможливо запустити.

У таких ситуаціях виручають насмішки, коли незалежно від того, яка ваша залежність запущена чи працює, ви завжди гарантовано запускаєте свою бізнес-логіку із запрограмованою відповіддю на залежність, яку викликають із тестового коду.

Види / категорії тестових пар

Макет - це, по суті, тип «Тестування подвійного» - це технічний жаргон. 'Тест подвійний' по суті означає об'єкт, який замінюється еквівалентним реальним екземпляром об'єкта або залежністю.

Існують різні типи тестових пар, як зазначено нижче:

# 1) Підробки:

Фейк - це робоча реалізація, подібна до реальної залежності, за винятком того факту, що вона є локальною для тестованої системи.

Приклад: Замість того, щоб вдаритись до реальної виробничої БД, тест використовує просту колекцію / пам’ять для зберігання даних.

Тип тестових пар - фальшивки

# 2) Заглушки:

Заглушки - це попередньо налаштовані відповіді, коли із системи, що перевіряється, викликається залежність.

Тип парних тестів - заглушки

# 3) Шпигуни:

Як випливає з назви, це насправді реальна функція (залежність) виклику з деяким механізмом спостереження. Опублікуйте дзвінок, можна перевірити, чи справді дзвінок був ініційований чи ні, разом із параметрами.

Тип тестових пар - шпигуни

# 4) Знущання:

Макети - це спеціальні екземпляри об'єктів, на які можна вказати затримані / попередньо налаштовані відповіді. Той факт, що фальшивий виклик можна перевірити як твердження в тесті.

Наприклад:

Існує функція генератора звітів, яка надсилає електронне повідомлення на вказану адресу під час виконання.

Оскільки ми не хочемо надсилати фактичні електронні листи, знову і знову, під час тестування, служба EmailService висміюється (а метод електронної пошти, який надсилає електронне повідомлення, налаштований так, щоб нічого не робити, коли його викликають). В кінці тесту ми можемо просто перевірити, чи метод надсилання електронної пошти служби електронної пошти викликаний через знущаний об'єкт.

Різні глузуючі рамки

Майже всі мови містять різні види глузуючих рамок. Ми будемо писати зразок коду за допомогою Mockito, який є відкритим кодом Mocking framework для Java.

Анатомія простого одиничного тесту з глузливою залежністю. Припустимо, ми намагаємось модульно протестувати додаток, яке обчислює загальну оцінку студента з усіх предметів і записує його в БД.

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 (). When (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. Тепер очікується, що тест повинен провалитися, оскільки це не очікуваний аргумент, з яким потрібно було викликати databaseUpdate.

@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 (“student1”, 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.

Майже 60-70% одиничних тестів, що включають макети, тести повинні мати подібну структуру. Mockito надає багато розширеної конфігурації / підтримки для великих потреб знущань, вводячи фіктивні екземпляри за допомогою ін'єкції залежностей, забезпечує Шпигунів насправді шпигувати за реальним викликом методу та перевіряти дзвінки.

У нашому підручнику буде розказано більше про концепцію знущань та шпигунів у Mockito.

НАСТУПНИЙ підручник

Рекомендована література

^