Введення у тестування
Велика програма це завжди висока ймовірність появи помилок. Без тестування додаток часто перевіряють вручну, а якщо додаток старий і з великим функціоналом іноді воно виглядає як чорний ящик. Тут на допомогу нам приходить автоматизоване тестування функціональності програми. Тестування це коли ми пишемо код, який автоматично перевіряє, чи не з'явилися помилки при внесенні змін до нашої програми.
У принципі, програмісти пишуть найчастіше модульне тестування. Модульне тестування виконує перевірку логіки програми на рівні функції чи методу; Модульне тестування застосовується до всіх видів додатків.
За підходом написання тести поділяються на два типи.
- Code first. Спочатку виконується розробка, а після вже тестування. Тобто спочатку відбувається написання коду, реалізується функціональність нашого додатку, а потім ми пишемо тест на реалізовану функціональність і тут вже або допрацьовуємо функціональність або переходимо до наступного завдання розробки
- Test first. Це інший підхід. Ще до написання функціональності нашої програми пишеться тест на майбутню функціональність. І лише після реалізації тестів ми переходимо до написання функціональності нашої програми.
Методологічно тести ділять на два види
- TDD - розробка через тестування (Test-Driven Development)
- BDD - розробка через реалізацію поведінки (Behavior-Driven Development).
Як у підходах TDD, так і в BDD, тести пишуться заздалегідь до написання фактичного коду. Написання тестів насамперед допомагає спрогнозувати хід розробки, що в кінцевому підсумку запобігає пропуску будь-яких моментів у функціональності роботи програми. Як видно зі схеми, BDD працює поверх TDD.
Алгоритм написання тестів TDD є наступним. Спочатку відбувається написання кількох тестів. Потім виконується запуск тестів і оскільки функціональність ще не реалізована вони зазнають невдачі. Ми приступаємо до реалізації необхідної функціональності програми, і поступово тести починають проходити, до повної реалізації функціональності.
Алгоритм написання тестів у BDD майже однаковий, але є стилістична різниця. BDD - визначає поведінку розробки програмного забезпечення, фактично ми робимо план перед написанням коду. Тести пишуться, з урахуванням що ми очікуємо від роботи ще не реалізованої функціональності. Підхід створено для того, щоб виправити проблеми, які можуть виникнути під час використання ТDD, а саме полегшити підтримку коду через наочне уявлення про його функціональність, тести та їх результати виглядають більш зрозумілими не тільки для програмістів, але й для замовника.
Важливим у розумінні тестування є тестова піраміда. Піраміда тестування використовується для розподілу тестів за рівнями програми.
Кожну програму можна розділити на кілька шарів. Розглянемо типове розшарування з рівнем компонентів, сервісами та інтерфейсом користувача. Нижня частина піраміди покрита модульними (unit) тестами. Вони написані здебільшого розробниками та охоплюють атомарні компоненти, такі як класи, методи та функції. Запускаються дуже часто, працюють швидко та їх кількість у рамках програми велика.
Інтеграційні тести. Це перевірка, чи не зламав новий реалізований функціонал код програми. Це сценарії, які охоплюють складніші функції, такі як тести API. Рідко запускаються, в основному при релізах та мерджах гілок.
У верхній частині знаходяться тести інтерфейсу користувача і ручного тестування. Їх ми розглядати не будемо, запускаються вони рідко та працюють повільно.