Лекція 131: Вступ до тестування: навіщо це потрібно

Уявіть собі світ, де розробники пишуть код, і він завжди працює ідеально. Здається фантастикою? На жаль, це не реальність — помилки неминучі. Наша задача — не лише написати красивий код, а й переконатися, що він працює так, як очікується.

Основні цілі тестування:

1. Зменшення ймовірності багів. Навіть досвідчений розробник може зробити помилку. Тести допомагають знаходити й виправляти їх ще до того, як код потрапить у продакшн.
2. Забезпечення якості застосунку. Застосунок має поводитися прогнозовано. Ніхто не хоче, щоб кнопка "оформити замовлення" раптом почала видаляти користувачів.
3. Впевненість у змінах. Коли ти додаєш нову функціональність, тести дають змогу бути впевненим, що старий код продовжує працювати коректно.
4. Економія часу на ручному тестуванні. Якщо щоразу перевіряти застосунок вручну, можна швидко втомитися. Тести автоматизують цей процес.

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

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

Unit-тести

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

Integration-тести

• Перевіряють, як різні компоненти застосунку працюють разом.
• Тут ми взаємодіємо з реальними ресурсами, такими як бази даних або зовнішні API.
• Вони менш ізольовані, ніж Unit-тести, але дають уявлення про реальну роботу системи.

Functional-тести

• Перевіряють роботу конкретного функціоналу застосунку з точки зору користувача.
• Наприклад, тест оплати товару від моменту додавання в кошик до отримання підтвердження.
• Часто вимагають автоматизованих інструментів для імітації дій користувача.

System-тести

• Перевіряють застосунок цілком, як єдину систему.
• Виявляють проблеми в конфігурації, інтеграції та взаємодії всіх частин системи.

Піраміда тестування

Для організації тестів часто використовують піраміду тестування:

/ Functional Tests \
/---------------------\
/  Integration Tests   \
/-----------------------\
/      Unit Tests        \

• Основа піраміди — Unit-тести (~70% тестів). Вони найдешевші й найшвидші, тому їх найбільше.
• Середній рівень — Integration-тести (~20%). Вони перевіряють взаємодію компонентів.
• Верхівка піраміди — Functional-тести (~10%). Їх складніше налаштувати, тому їх пишуть менше.

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

Де і коли ми пишемо тести?

Чим раніше, тим краще

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

Ось чому важливо писати тести відразу при розробці нового функціоналу. Такий підхід називається TDD — Test Driven Development (розробка через тестування). Але про це ми поговоримо детальніше у наступних лекціях.

Правильний момент

• Unit-тести пишуться в процесі розробки конкретного методу або класу.
• Integration-тести створюються після завершення інтеграції всіх частин функціоналу.
• Functional-тести додаються на останньому етапі тестування, перед випуском у продакшн.

Реальна користь від тестів. А воно точно потрібно?

Можливо, хтось із вас вже замислюється: "А чи не можна обійтися без тестів? Все ж QA все перевірить". Гарне питання! Давайте розберемося.

1. QA-тестери знайдуть дефекти в застосунку, але їхня задача — перевіряти готовий продукт. Автоматизовані тести допомагають розробникам знаходити помилки на більш ранніх етапах.
2. Тести знижують ризик. Ти впевнений, що зміна в одній частині коду не зламає іншу. Наприклад, ти змінив логіку роботи API, і твій Unit-тест одразу скаже, якщо десь допущена помилка.
3. Підвищення довіри. Для командної розробки наявність тестів дозволяє всім учасникам команди бути впевненими в стабільності коду.

Глобальна картина

Уявіть великий проект із кількома командами розробників. Кожен пише свій функціонал, вносить зміни і фіксить баги. Але як переконатися, що застосунок в підсумку працює так, як треба? Відповідь очевидна: через тестування. Це як страховка для розробників, де ви отримуєте впевненість, що все йде за планом.

Що ми сьогодні дізналися:

• Тести — необхідна частина процесу розробки, і вони економлять час на пошуку багів.
• Існує кілька видів тестів, від Unit-тестів до функціональних.
• Піраміда тестування допомагає розподілити зусилля: більше Unit-тестів, менше функціональних.
• Тести не лише про баги, а й про впевненість у якості продукту.

У наступних лекціях ми зануримося у практичну реалізацію тестування. Ми почнемо з написання простих Unit-тестів з використанням JUnit 5 і познайомимося з потужними бібліотеками, такими як Mockito, а потім перейдемо до інтеграційних тестів. Готуйтеся до цікавих прикладів і практики!