• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

TDD (Test-Driven Development)

TDD є однією з основоположних частин XP (eXtreme Programming). Ідеї, покладені в основу XP, направлені на те, щоб зробити процес розробки ПЗ простішим і мати короткі, повторювані цикли розробки з постійним зворотнім зв’язком щодо стану програмної системи. TDD дає можливість розробляти складні програмні системи шляхом виконання простих ітерацій, в яких тести задають напрямок розвитку дизайну та реалізації системи.

Найскладнішим у використанні TDD є зміна уявлень програміста про способи побудови коду програми. Замість створення проекту, який описує, які програмні одиниці потрібно створити, створюються тести, кожен з яких описує, як повинна функціонувати маленька програмна одиниця системи. Ці тести визначають дизайн коду, який буде реалізовувати дані програмні одиниці системи.

TDD базується на двох методологіях – unit-тестуванні та рефакторингу. Загальна схема розробки при використанні TDD така:

1. Написати тест, який визначає, як, на думку автора, маленька програмна одиниця повинна поводитись.

2. Створити програмну одиницю якомога простішими засобами так, щоб вона пройшла тест.

3. Здійснити рефакторинг коду, зробивши його більш якісним і перевіряючи за допомогою тестів його правильність після внесення кожної зміни.

Оскільки TDD є ітеративним процесом, то потрібно повторювати дані кроки, поки не буде досягнуто бажаної якості коду.

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

Приклад. Однією з вимог до програми є визначити процент влучності баскетболіста за гру та за сезон. З вимоги можна визначити ряд дій, які повинна робити програмна одиниця:

– ідентифікувати гравця;

– ввести дані, необхідні для визначення проценту влучності в грі;

– ідентифікувати гру;

– обрахувати середній процент влучності за гру;

– обрахувати процент влучності за сезон.

Зробивши спрощене припущення, що гравці ідентифікуватимуться за ім’ям, а ігри за датою, можна написати код:

Написавши даний тест, маємо, що потрібно створити класи PlayerList та Player. В PlayerList повинен бути метод getPlayer(String), а в Player – addGameA(String, int, int), getGameA(String), getA().

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

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

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

Переглядів: 603