Java Unit Testing: методики, поняття, практика

Сьогодні і не зустрінеш програми, не обвішані тестами, тому ця тема буде як ніколи актуальна для розробників-початківців: без тестів — нікуди. На правах реклами запропонуватиму переглянути мої минулі статті. У деяких із них зачіпаються тести (та й так статті будуть дуже корисні):

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

Види тестування

Що таке тест? Як говорить Вікі: « Тест або випробування - спосіб вивчення глибинних процесів діяльності системи за допомогою приміщення системи в різні ситуації та відстеження доступних спостереженню змін у ній». Іншими словами, це перевірка правильності роботи нашої системи у тих чи інших ситуаціях. Все про Unit testing: методики, поняття, практика - 2

Все про Unit testing: методики, поняття, практика - 2

Що ж, побачимо, які взагалі є види тестування:

Модульне тестування (unit testing) – тести, завдання яких перевірити кожен модуль системи окремо. Бажано, щоб це були мінімально поділені шматочки системи, наприклад, модулі.
Системне тестування (system testing) — тест високого рівня перевірки роботи більшого шматка програми чи системи загалом.
Регресійне тестування (regression testing) — тестування, яке використовується для перевірки того, чи не впливають нові фічі або виправлені баги на існуючий функціонал програми та чи не з'являються старі баги.
Функціональне тестування (functional testing ) - перевірка відповідності частини додатку вимогам, заявленим у специфікаціях, юзерстор і т.д.

Види функціонального тестування:
- тест «білої скриньки» (white box) на відповідність частини додатку вимогам із знанням внутрішньої реалізації системи;
- тест «чорної скриньки» (black box) на відповідність частини додатку вимогам без знання внутрішньої реалізації системи.
Тестування продуктивності (performance testing) — вид тестів, які пишуться визначення швидкості відпрацювання системи чи її частини під певним навантаженням.
Тестування навантаження (load testing) — тести, призначені для перевірки стійкості системи при стандартних навантаженнях і для знаходження максимально можливого піку, при якому додаток працює коректно.
Стрес-тестування (stress testing) — вид тестування, призначений для перевірки працездатності програми при нестандартних навантаженнях і визначення максимально можливого піку, при якому система не впаде.
Тестування безпеки (security testing) – тести, що використовуються для перевірки безпеки системи (від атак хакерів, вірусів, несанкціонованого доступу до конфіденційних даних та інших радощів життя).
Тестування локалізації (localization testing ) - це тести локалізації для програми.
Юзабіліті тестування (usability testing) - вид тестування, спрямований на перевірку зручності використання, зрозумілості, привабливості та навчання для користувачів.

Все про Unit testing: методики, поняття, практика - 4

Unit — модульні тести, що застосовуються в різних шарах програми, що тестують найменшу логіку прикладної програми: наприклад, клас, але найчастіше — метод. Ці тести зазвичай намагаються максимально ізолювати від зовнішньої логіки, тобто створити ілюзію того, що решта програми працює в стандартному режимі.

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

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

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

Сьогодні докладно розглянемо найвикористаніші тести — юніт-тести, тому що вміти ними користуватися на базовому рівні повинні всі Java-розробники, що поважають себе.

Ключові поняття юніт-тестування

Покриття тестів

матеріал про Code Coverage на JavaRush і на Хабрі ;
фундаментальна теорія тестування .

TDD (Test-driven development)

Все про Unit testing: методики, поняття, практика - 6

Пишемо наш тест.
Запускаємо тест, пройшов він чи ні (бачимо, що все червоне не психуємо: так і має бути).
Додаємо код, який має задовольнити цей тест (запускаємо тест).
Виконуємо рефакторинг коду.

BDD (Behavior-driven development)

Тестовий сценарій (Test Case)

Фікстури (Fixture)

Етапи тестування

Завдання тестованих даних (фікстур).
Використання тестованого коду (виклик тестованого методу).
Перевірка результатів та звірка з очікуваними.

Все про Unit testing: методики, поняття, практика - 7

Мок

Заглушки

Spy

stubs

mock

Середовище тестування

@Test

@Before

@After

@ BeforeClass

@AfterClass

@Ignore

@ Test

@ Test (timeout = 100)

@Mock

@RunWith(MockitoJUnitRunner.class)

assertEquals(Object expecteds, Object actuals)— перевіряє, чи рівні об'єкти, що передаються.
assertTrue(boolean flag)- Перевіряє, чи повертає передане значення - true.
assertFalse(boolean flag)- Перевіряє, чи повертає передане значення - false.
assertNull(Object object)– перевіряє, чи об'єкт є нульовим (null).
assertSame(Object firstObject, Object secondObject)- Перевіряє, чи посилаються передані значення на один і той же об'єкт.
assertThat(T t, Matcher<T> matcher)- Перевіряє, чи задовольняє t умові, вказаній у matcher.

assertThat(firstObject).isEqualTo(secondObject)

Практика тестування

<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-test</artifactId>
   <version>2.2.2.RELEASE</version>
   <scope>test</scope>
</dependency>

@Service
@RequiredArgsConstructor
public class RobotServiceImpl implements RobotService {
   private final RobotDAO robotDAO;

   @Override
   public Robot update(Long id, Robot robot) {
       Robot found = robotDAO.findById(id);
       return robotDAO.update(Robot.builder()
               .id(id)
               .name(robot.getName() != null ? robot.getName() : found.getName())
               .cpu(robot.getCpu() != null ? robot.getCpu() : found.getCpu())
               .producer(robot.getProducer() != null ? robot.getProducer() : found.getProducer())
               .build());
   }
}

@RunWith(MockitoJUnitRunner.class)
public class RobotServiceImplTest {
   @Mock
   private RobotDAO robotDAO;

   private RobotServiceImpl robotService;

   private static Robot testRobot;

   @BeforeClass
   public static void prepareTestData() {
       testRobot = Robot
               .builder()
               .id(123L)
               .name("testRobotMolly")
               .cpu("Intel Core i7-9700K")
               .producer("China")
               .build();
   }

   @Before
   public void init() {
       robotService = new RobotServiceImpl(robotDAO);
   }

@Test
public void updateTest() {
   when(robotDAO.findById(any(Long.class))).thenReturn(testRobot);
   when(robotDAO.update(any(Robot.class))).then(returnsFirstArg());
   Robot robotForUpdate = Robot
           .builder()
           .name("Vally")
           .cpu("AMD Ryzen 7 2700X")
           .build();

   Robot resultRobot = robotService.update(123L, robotForUpdate);

   assertNotNull(resultRobot);
   assertSame(resultRobot.getId(),testRobot.getId());
   assertThat(resultRobot.getName()).isEqualTo(robotForUpdate.getName());
   assertTrue(resultRobot.getCpu().equals(robotForUpdate.getCpu()));
   assertEquals(resultRobot.getProducer(),testRobot.getProducer());
}

Все про Unit testing: методики, поняття, практика - 9

Все про Unit testing: методики, поняття, практика - 10

Отже, підіб'ємо підсумки:

Все про Unit testing: методики, поняття, практика - 11