модульне тестування

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

Unit (Елемент) - найменший компонент, який можна скомпілювати.

Драйвери - модулі тестів, які запускають тестований елемент.

Заглушки - замінюють відсутні компоненти, які викликаються елементом і виконують такі дії:

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

White-box testing. Для конструювання тестів використовуються внутрішня структура коду і керуюча логіка. При цьому існує ймовірність, що код буде перевірятися так, як він був написаний, а це не гарантує коректність логіки.

Black-box testing. Для конструювання тестів використовуються вимоги і специфікації ПО. недоліки:

таким способом неможливо знайти взаимоуничтожаются помилок,
деякі помилки виникають досить рідко (помилки роботи з пам'яттю) і тому їх важко знайти і відтворити

Стратегія модульного тестування

Модульне тестування є однією з ключових практик методології екстремального програмування. Прихильники XP наводять такі аргументи на захист цієї практики:

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

Згоден, входження в робочий ритм - благородне завдання. Впевненість в працездатності - теж добре. Але «впевненості в працездатності» я вважаю за краще дійсно працездатний код. Нехай навіть при цьому я не зовсім «впевнений».

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

На мій погляд, модульне тестування виправдано, якщо воно:

Знижує час на налагодження
Дає можливість пошуку помилок з меншими витратами, ніж при інших підходах
Дає можливість дешевого пошуку помилок при змінах коду в подальшому

Сумарний виграш від застосування модульних тестів повинен бути більше, ніж витрати на їх створення і підтримання в актуальному стані.

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

Мета модульного тестування:

Отримання працездатного коду з найменшими витратами. І його застосування виправдане тоді і тільки тоді, коли воно дає більший ефект, ніж інші методи.

Звідси випливає кілька висновків:

Немає сенсу писати тести на весь код. Деякі помилки простіше знайти на більш пізніх стадіях. Так, наприклад, для ООП дане правило може звучати так: немає сенсу писати тести на клас, який використовується тільки одним класом. Ефективніше написати тести на викликає клас і створити тести тестуючі всі ділянки коду.
Писатимуть тести для коду потенційно схильної змін вигідніше, ніж для коду, зміна якого не передбачається. Складна логіка змінюється частіше, ніж проста. Отже, в першу чергу має сенс писати модульні тести на складну логіку. А на просту логіку писати пізніше або взагалі тестувати іншими методами.
Для того щоб якомога рідше змінювати тести слід добре планувати інтерфейси. Те ж саме можна сказати і стосовно написання вихідного коду. Дійсно, створення оптимальної архітектури часто визначає подальший хід проекту. І є оптимум, на якому етапі архітектура «досить хороша». Все так, але я хочу сказати про інше:

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

планування тестів

Перше питання, яке постає перед нами: «Скільки потрібно тестів». Відповідь, яку часто дається: тестів має бути стільки, щоб не залишилося неоттестірованних ділянок. Можна навіть ввести формальне правило:

В першу чергу тести повинні відповідати не коду, а вимогам. Правило, яке слід застосовувати:

Тести повинні базуватися на специфікації.