Page 109 - 4190

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

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

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

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

клас буде виконувати певну роль, як правило, невелику. Як наслідок,
залежності між класами будуть понижуватися, а зачеплення – збіль-
шуватися. Контрактне програмування ( design by contract) доповнює

тестування, формуючи необхідні вимоги через ствердження ( design
by contract).
Хоча, при розробленні через тестування необхідно написати зна-

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

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

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

При роботі з кодом, на якому немає тестів, помилку можна виявити
через певний час, коли з кодом працювати буде набагато складніше.
Добре протестований код легко переносить рефакторинг. Впевненість

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

бе вільніше при внесенні архітектурних рішень, які повинні покращи-
ти дизайн коду.

109