и.
Однією з головних проблем автоматизованого тестування є його трудомісткість: незважаючи на те, що воно дозволяє усунути частина рутинних операцій і прискорити виконання тестів, великі ресурси можуть витрачатися на оновлення самих тестів. Це відноситься до обох видів автоматизації. При рефакторінгу часто буває необхідно відновити і модульні тести, а зміна коду тестів може зайняти стільки ж часу, скільки і зміна основного коду. З іншого боку, при зміні інтерфейсу додатку необхідно наново переписати всі тести, які пов'язані з оновленими вікнами, що при великій кількості тестів може відняти значні ресурси.
Модульне тестування.
Модульне тестування, або юніт-тестування (англ. unit testing ) - процес у програмуванні, що дозволяє перевірити на коректність окремі модулі вихідного коду програми.
Ідея полягає в тому, щоб писати тести для кожної нетривіальною функції або методу. Це дозволяє досить швидко перевірити, чи не призвело чергове зміна коду до регресії, тобто до появи помилок у вже оттестировать місцях програми, а також полегшує виявлення та усунення таких помилок.
Переваги.
Мета модульного тестування - ізолювати окремі частини програми і показати, що окремо ці частини працездатні.
Цей тип тестування зазвичай виконується програмістами.
Заохочення змін.
Модульне тестування пізніше дозволяє програмістам проводити рефакторинг, будучи впевненими, що модуль раніше працює коректно (регресійне тестування). Це заохочує програмістів до змін коду, оскільки досить легко перевірити, що код працює і після змін.
Спрощення інтеграції.
Модульне тестування допомагає усунути сумніви з приводу окремих модулів і може бути використане для підходу до тестування знизу вгору raquo ;: спочатку тестуються окремі частини програми, потім програма в цілому.
Документування коду.
Модульні тести можна розглядати як живий документ для тестованого класу. Клієнти, які не знають, як використовувати даний клас, можуть використовувати юніт-тест як приклад.
Відділення інтерфейсу від реалізації.
Оскільки деякі класи можуть використовувати інші класи, тестування окремого класу часто поширюється на пов'язані з ним. Наприклад, клас користується базою даних; в ході написання тесту програміст виявляє, що тесту доводиться взаємодіяти з базою. Це помилка, оскільки тест не повинен виходити за границю класу. У результаті розробник абстрагується від з'єднання з базою даних і реалізує цей інтерфейс, використовуючи свій власний mock-об'єкт. Це призводить до менш пов'язаному кодом, мінімізуючи залежності в системі.
Обмеження.
Як і кожна технологія тестування, модульне тестування не дозволяє відловити всі помилки програми. Справді, це випливає з практичної неможливості трасування всіх можливих шляхів виконання програми, за винятком найпростіших випадків. Крім того, відбувається тестування кожного з модулів окремо. Це означає, що помилки інтеграції, системного рівня, функцій, виконуваних в декількох модулях, не будуть визначені. Крім того, дана технологія марна для проведення тестів на продуктивність. Таким чином, модульне тестування більш ефективно при використанні в поєднанні з іншими методиками тестування.
Тестування програмного забезпечення - комбінаторна задача. Наприклад, кожне можливе значення булевою змінної потребують двох тестів: один на варіант TRUE, інший - на варіант FALSE. У результаті на кожен рядок вихідного коду потрібно 3-5 рядків тестового коду.
Для отримання вигоди від модульного тестування потрібно строго слідувати технології тестування на всьому протязі процесу розробки програмного забезпечення. Потрібно зберігати не тільки записи про всі проведених тестах, але і про всі зміни вихідного коду у всіх модулях. З цією метою слід використовувати систему контролю версій ПЗ. Таким чином, якщо більш пізня версія ПЗ не проходить тест, який був успішно пройдений раніше, буде нескладним звірити варіанти вихідного коду і усунути помилку. Також необхідно переконатися в незмінному відстеженні і аналізі невдалих тестів. Ігнорування цієї вимоги призведе до лавиноподібного збільшення невдалих тестових результатів.
Програми модульного тестування.
Екстремальне програмування.
Екстремальне програмування припускає як один з постулатів використання інструментів автоматичного модульного тестування. Цей інструментарій може бути створений або третьою стороною (наприклад, Boost.Test), або групою розробників цього додатка.
В ек...
