Unit тест — це невелика програма, яка тестує роботу окремого відрізка коду. Завдання тесту — переконатися, що саме ця ділянка коду функціонує нормально, виконує своє завдання в різних умовах, і не заважає роботі інших ділянок коду та всього продукту.
Не всі розробники люблять unit-тести: вони забирають багато часу. Коли щоразу unit тест показує, що код працює нормально, навіщо тестувати те, що і так працює? Але в комерційній розробці нікуди без тестування, включаючи розробку на Java. Поговоримо про java unit тести, як вони працюють і коли їх потрібно використовувати.
Будь-який програмний продукт, код якого не покритий тестами, приречений на повільну болісну смерть. Навіть якщо спочатку така програма працює нормально, досить швидко вона починає збоїти, видавати помилки, і зрештою працювати з нею стає неможливо. Навіть якщо така програма функціонує, ніхто не розуміє, що відбувається всередині, якщо розробники коду давно покинули проект.
Тести використовуються на різних рівнях: наприклад, верхівневі тести перевіряють програму на відповідність бізнес-логіці. Але для тестування окремого модуля зовсім необов’язково проганяти всю програму через повний сценарій користувача. Достатньо ізолювати потрібний відрізок коду та змусити його виконати свою функцію. Це і є Unit тестування — “unit” перекладається як модуль.
Тестування може бути ручним та автоматизованим, але якщо йдеться про Unit тести, вони частіше бувають автоматичними. При ручному тестуванні використовується покрокова інструкція. Автоматичний Unit test — це невелика програма, яка емулює дії користувача. Unit тестами можна перевіряти окрему функцію, процедуру, метод, модуль чи об’єкт.
Створенням Unit тестів займаються тестувальники-автоматизатори чи розробники. Модульне тестування може бути простим або складним, залежно від стратегій, принципів та інструментів тестування у команді. Головне, що не слід забувати: тести повинні не тільки існувати в системі, але запускатися і підтримуватися. Інакше жодного сенсу у їхньому написанні немає.
Є кілька основних сценаріїв, за яких варто писати Unit тести.
При легкому рефакторингу, тобто внесенні елементів в код, модульне тестування дозволить швидко виявити проблеми нових елементів коду.
Інтеграційне тестування — це тести вищого рівня, під час яких перевіряється взаємодія різних модулів програми між собою. Unit тести можуть бути частиною інтеграційного тестування.
При написанні Unit тесту створюється документ, який визначає завдання тесту. Чим більше таких документів у продукті, тим простіше його підтримка та оновлення, особливо коли змінюються розробники.
Існує підхід, популярний у комерційній розробці, при якому спочатку пишуться тести та документація на них, згідно з архітектурою майбутньої програми. Тести задають класи, методи та особливості їхньої поведінки. Потім створюється код і різні елементи коду можуть використовуватися тільки за умови, що вони пройшли тести. Цей кропіткий підхід вимагає часу, проте готовий код повністю протестований і задокументований.
Почнемо з того, що для Unit тестів можна використовувати різні фреймворки. Добре підібраний фреймворк робить створення Unit тестів швидшим та простішим. Так, якщо написання тесту для обраного юніту з нуля може тривати кілька годин, то з фреймворком час скорочується до хвилин.
Існує безліч різних фреймворків для різних мов програмування, зокрема, і для Java. Треба сказати, деякі мови краще підходять для модульного тестування, ніж інші, і Java, звичайно, нагорі списку. Синтаксис Java дозволяє створити модульні тести без використання додаткових бібліотек.
JUnit — це фреймворк для створення модульних текстів на мові Java. Він входить до сімейства фреймворків xUnit для різних мов програмування. JUnit породив систему розширень, включаючи відомий інструмент автоматизації роботи у веб-браузері Selenium. Завдяки Junit були створені, опрацьовані та покращені концепції тестування ПЗ — як, що і коли треба тестувати.
У четвертій версії JUnit з’явилися інструкції. Це метадані, які можуть бути додані в код Java, щоб зробити його простішим для читання. Анотації можна додавати до методів, класів та змінних.
Наприклад, анотація @Before використовується, зокрема, щоб перед java unit тестом виконати певну логіку, наприклад обробити якийсь оператор. Так само працює інструкція @After, тільки логіка виконується після тесту. Анотація @Ignore дозволяє ігнорувати певні умови. Повний список анотацій потрібно дивитися в описі JUnit, починаючи з четвертої версії.
Багатьом розробникам не подобається писати тести, включаючи java unit тести. Це вважається нудною роботою порівняно з написанням коду. Але річ у тому, що без тестування можна створювати лише проекти-одноденки, життєвий термін яких — кілька місяців.
У будь-якому більш-менш серйозному комерційному продукті без тестів не обійтись. Занадто великі ризики, з якими може зіткнутися замовник у разі використання неякісного ПЗ. Уявіть собі лікарню, енергостанцію чи космічний корабель, на яких заглючив код та сталася аварія. Адже такі випадки реально бували. Та й бізнес, у якого стали всі процеси, бо новий реліз поклав систему, навряд чи буде задоволений.
Тому тести треба писати. Необов’язково покривати тестами 100% коду, але якісне тестування — запорука успішного програмного продукту.