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

У цій статті я спробував описати процес створення юніт-тестів, виходячи з власного досвіду.

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

Отже. Вам потрібно протестувати певний сервіс. Почніть зі створення класу, який буде зберігати методи для тестування. Зазвичай такі класи розміщують у папці tests. Я користуюся інструментом IntelliJ IDEA. Перебуваючи в класі, який потрібно протестувати, я просто натискаю комбінацію Ctrl+Shift+T, і додаток перенаправляє мене в тестовий клас. Або якщо такого ще немає – пропонує створити.

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

• які вхідні дані йому потрібні;
• які сторонні класи використовує метод у своїй роботі;
• що він повинен повернути у випадку успішної роботи;
• що він поверне, коли, наприклад, сторонній метод поверне не той результат, який він очікує;
• що буде повернено, якщо вхідні дані будуть не ті, які він очікує.

Усі ці моменти потрібно переглянути та проаналізувати. Особливо непросто тестувати метод, який виконує кілька дій. Саме тому потрібно дотримуватися принципу SOLID (Single responsibility). Так і код буде виглядати приємніше, і тестувати його буде легше.

Далі потрібно підготувати вхідні дані, які потрібні методу. Потім замокати поведінку сторонніх методів, які він використовує у своїй роботі.

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

Тепер більш детально.

Підготувати вхідні дані. Це досить просто. Дивимося, які об’єкти або параметри приймає тестований метод, і створюємо їх. Якщо це великий об’єкт – краще створювати тестові дані в окремому класі. Щоб не захаращувати тестові файли.

Замокати поведінку методів і класів, які використовує тестований метод.

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

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

Для того, щоб порівняти результат виконання методу з очікуваним – є маса бібліотек, які дуже прості у використанні. Перше, що спадає на думку всім програмістам Java – бібліотека JUnit. Детальніше про неї є маса інформації в мережі. Уточню лише, що це достатньо потужний і гнучкий інструмент для написання юніт-тестів. Особливо останні версії JUnit, які дозволяють протестувати буквально всі сценарії з мінімальною кількістю коду.

Не потрібно писати тести заради тестів. Тест повинен покрити певний сценарій, який, на думку програміста, може статися насправді.

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

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

Написання юніт-тестів – це робота, яка не видна замовнику. Вони не наповнюють ваш додаток функціоналом. Можливо, саме тому дуже часто програмісти ігнорують цю стадію процесу при розробці додатків. АЛЕ! У довгостроковій перспективі – тести (не тільки юніт) прискорюють розробку і повністю окупають себе фінансово. Коли тестом можна виловити баг, який би коштував фірмі втрати грошей або репутації – тоді написання тестів по-справжньому себе виправдовує.

Тому не ігноруйте тести у своїх додатках (особливо Unit). Оскільки це дуже важлива і цінна частина розробки додатку.

Я записав невелике відео, де на прикладі показав, як можна покрити тестами практично всі шари веб-додатку.