stify"> · Архітектура програми повинна базуватися на використанні безлічі сильно пов'язаних компонентів, які слабо зчеплені один з одним, завдяки чому тестування коду спрощується.
Два згаданих правила TDD визначають порядок етапів програмування:
1. Червоний - напишіть невеликий тест, який не працює, а можливо, навіть не компілюється.
2. Зелений - змусьте тест працювати якомога швидше, при цьому не думайте про правильність дизайну і чистоті коду. Напишіть рівно стільки коду, щоб тест спрацював.
. Рефакторинг - видаліть з написаного вами коду будь дублювання.
Освоївши TDD, розробники виявляють, що вони пишуть значно більше тестів, ніж раніше, і рухаються вперед маленькими кроками, які раніше могли здатися безглуздими.
Змусивши тест працювати, ми знаємо, що тепер тест працює, відтепер і навіки. Ми стали на крок ближче до завершення роботи, ніж ми були до того, як тест спрацював. Після цього ми змушуємо другий тест працювати, потім третій, четвертий і т.д. Чим складніше проблема, що стоїть перед програмістом, тим меншу область функціональності повинен покривати кожен тест.
Безумовно існують завдання, які неможливо (принаймні, на поточний момент) вирішити тільки за допомогою тестів. Зокрема, TDD не дозволяє механічно продемонструвати адекватність розробленого коду в області безпеки даних та взаємодії між процесами. Безумовно, безпека заснована на коді, в якому не повинно бути дефектів, однак вона заснована також на участі людини в процедурах захисту даних. Тонкі проблеми, що виникають у сфері взаємодії між процесами, неможливо з упевненістю відтворити, просто запустивши деякий код.
У 1999 році при своїй появі розробка через тестування була тісно пов'язана з концепцією «спочатку тест» (англ. lt; # justify gt; 7.2 Вимоги
Розробка через тестування вимагає від розробника створення автоматизованих модульних тестів, що визначають вимоги до коду безпосередньо перед написанням самого коду.
Тест містить перевірки умов, які можуть або виконуватися, або ні. Коли вони виконуються, кажуть, що тест пройдено. Проходження тесту підтверджує поведінку, предполагаемое програмістом. Розробники часто користуються бібліотеками для тестування (англ. Lt; # justify gt; 7.3 Цикл розробки через тестування
Графічне представлення циклу розробки, у вигляді блок-схеми (Додаток 1).
Наведена послідовність дій заснована на книзі Кента Бека «Розробка через тестування: на прикладі».
. 4 Запуск всіх тестів: переконатися, що нові тести не проходять
На цьому етапі перевіряють, що щойно написані тести не проходять. Цей етап також перевіряє самі тести: написаний тест може проходити завжди і відповідно бути марним. Нові тести повинні не проходити по з'ясованими причин. Це збільшить впевненість (хоча не гарантуватиме повністю), що тест справді тестує те, для чого він був розроблений.
. 5 Запуск всіх тестів: переконатися, що всі тести проходять
Якщо всі тести проходять, програміст може бути впевнений, що код задовольняє всім тестованим вимогам. Після цього можна приступити до завершального етапу циклу.
. 6 Рефакторинг
Коли досягнута необхідна функціональність, на цьому етапі код може бути почищений. Рефакторинг lt; # justify gt; 7.7 Стиль розробки
Розробка через тестування тісно пов'язана з такими принципами як
«роби простіше, дурник» (англ. lt; # justify gt; 7.8 Переваги
дослідження 2005 року показало, що використання розробки через тестування передбачає написання більшої кількості тестів, у свою чергу, програмісти, які пишуть більше тестів, схильні бути більш продуктивними. Гіпотези зв'язують якість коду з TDD були непереконливі. Програмісти, що використовують TDD на нових проектах, відзначають, що вони рідше відчувають необхідність використовувати відладчик. Якщо деякі з тестів несподівано перестають проходити, відкат до останньої версії, яка проходить всі тести, може бути більш продуктивним, ніж налагодження.
Розробка через тестування пропонує більше, ніж просто перевірку коректності, вона також впливає на дизайн програми. Спочатку сфокусувавшись на тестах, простіше уявити, яка функціональність необхідна користувачеві. Таким чином, розробник продумує деталі інтерфейсу до реалізації. Тести змушують робити свій код більш пристосованим для тестування. Наприклад, відмовлятися від глобальних змінних, одинаків (singletons), робити класи менш пов'язаними і легкими для використання. Міцно зв`язаний код або код, який вимагає складної ініціалізації, буде знач...
