Page 107 - 4190

ти тест, розробник повинен чітко розуміти пред’явлені до нової мож-
ливості вимоги. Для цього розглядаються можливі стандарти викори-
стання і можливі історії використання користувачів. Нові вимоги мо-
жуть також вплинути на зміни існуючих тестів. Це відрізняє розробку

через тестування від технік, коли тести пишуться після того, як код
уже написано: вона заставляє розробника зосередити увагу на вимо-
гах до написання коду – тонка, але важлива відмінність.

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

впевненість (хоча не буде гарантувати повністю), що тест дійсно тес-
тує те, для чого він був розроблений.
На етапі написання нового коду він пишеться так, щоб тест про-

ходив. Цей код не обов’язково повинен бути ідеальний. Допустимо,
що він проходить тест яким-небудь не елегантним способом. Це мо-
жливо, оскільки наступні етапи покращать і від полірують його. Важ-

ливо писати код, що призначений для тільки для проходження тесту.
Не слід додавати зайвої функціональності і, яка відповідно не тесту-
ється.

На наступному етапі необхідно запустити усі тести і переконати-
ся, що усі вони проходять. Якщо усі тести проходять, то програміст
може бути впевнений, що код відповідає усім вимогам тестування.
Після цього можна приступити до заключного етапу циклу – рефак-

торингу.
Коли досягнута потрібна функціональність, на цьому етапі код
можна почистити. Рефакторинг – процес зміни внутрішньої структу-

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

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

до налагодження. При використання сторонніх бібліотек не слід ро-
боти такі зміни, що приводять до тестування самої сторонньої бібліо-
теки, а не код, що її використовує, якщо немає підозри, що бібліотека

має помилки.
Розроблення через тестування тісно пов’язане з таким принципом

107