Розробка через тестування
| Цикл розробки програмного забезпечення |
|
|---|---|
 Програміст за роботою |
|
| Діяльність та кроки | |
| Вимоги · Специфікація Архітектура · Дизайн Реалізація · Тестування Розгортання · Підтримка |
|
| Методології | |
| Гнучка · Чистого приміщення DSDM · Iterative · RAD · RUP Spiral · Водоспад · XP · Scrum Lean · V-Model · FDD · TDD |
|
| Допоміжні дисципліни | |
| Конфігураційне керування Документування Якість ПЗ Управління проектами User experience design |
|
| Інструменти | |
| Компілятор · Зневаджувач Профілювальник GUI designer · IDE |
|
Розробка через тестування (англ. Test-driven development (TDD)) — технологія розробки програмного забезпечення, яка використовує короткі ітерації розробки, що базуються на попередньому написанні тестів, які визначають необхідні покращення або нові функції. Кожна ітерація має на меті розробити код, який пройде ці тести. Нарешті, програміст або група вдосконалюють код для погодження змін. Один із ключових моментів TDD полягає у тому, що підготовка тестів перед написанням самого коду пришвидшує процес внесення змін. Варто зауважити, що розробка через тестування є методологією розробки програмного забезпечення, а не його тестування.
Test-Driven Development відноситься до концепції екстремального програмування, яка стверджує, що першим ділом потрібно писати теста, а вже потім код, яка веде свій початок з 1999 року,[1] однак, останнім часом спостерігається загальніший інтерес до даної методології.[2]
Програмісти також використовують дану методологію для вдосконалення і зневадження коду, раніше написаного з використанням інших методологій розробки.[3]
Зміст |
Вимоги [ред.]
Розробка через тестування вимагає від розробників написання автоматизованих тестів, які визначають вимоги до коду, до написання самого коду. Тести складаються з тверджень, які можуть бути правдивими, або ж хибними. Запустивши тести, розробники швидко отримують інформацію про правильність або неправильність поведінки їхнього коду. Розробники також часто використовують різноманітні каркаси, які переважно будуються на основі xUnit для створення і регулярного автоматичного запуску тестів.
Цикл розробки за методологією TDD [ред.]
Усе нижчевказане базується на книзі Test-Driven Development by Example,[4] котру багато хто вважає канонічним текстом про дану концепцію у її сучасному вигляду.
1. Додати тест [ред.]
У розробці через тестування, реалізація кожної нової функції розпочинається з написання тесту. Цей тест звісно ж. не буде проходити, адже він написаний до того, як було реалізовано даний функціонал. Для того, щоб написати тест, розробник повинен чітко розуміти майбутні специфікацію та вимоги до нового функціоналу. Це основна відмінність розробки через тестування від більш класичного підходу написання тестів після того, як написано сам код: це змушує розробника фокусуватись на специфікаціях перед написанням коду.
2. Запустити усі тести, і подивитись, чи вони пройшли [ред.]
Це підтверджує, що усі тести працюють коректно, і, що нові тести помилково не проходять, не вимагаючи при цьому ніякого нового коду.
Нові тести також не повинні проходити з відомої причини. Цей етап є тестуванням самих тестів на те, чи дають вони негативний результат: це виключає можливість того, що новий тест буде завжди проходити, а, отже, буде марним.
3. Написати код [ред.]
Наступним кроком є написання коду, який змусить тест пройти. Новий код, написаний на даному етапі не буде досконалим, і може, наприклад, змушувати тест проходити у некоректний спосіб. Це є допустимим. тому що на наступних кроках даний код буде поліпшуватись і відточуватись.
Дуже важливим моментом є те, що код написаний виключно для того, щоб проходили тести; ніякої додаткової (а отже і не протестованої) функціональності на даному етапі вносити не дозволяється.
4. Запустити автоматичні тести, і подивитись, чи пройшли вони успішно [ред.]
Якщо усі тести успішно проходять, програміст може бути впевненим у тому, що його код відповідає усім вимогам, які перевіряються тестами. Це гарна точка, з якої можна перейти на фінальний етап циклу розробки.
5. Удосконалити код [ред.]
Тепер код при необхідності може бути "вичищений". Шляхом перезапуску усіх тестів, розробник може впевнитись у тому, що рефакторинг коду не порушив його відповідність специфікаціям. Концепція вилучення з коду дублікатів є важливим аспектом будь якого дизайну програмного забезпечення.
Джерела інформації [ред.]
- ↑ "Extreme Programming", Computerworld (online), December 2001, webpage: Computerworld-appdev-92.
- ↑ Newkirk, JW and Vorontsov, AA. Test-Driven Development in Microsoft .NET, Microsoft Press, 2004.
- ↑ Feathers, M. Working Effectively with Legacy Code, Prentice Hall, 2004
- ↑ Beck, K. Test-Driven Development by Example, Addison Wesley, 2003
