Page 106 - 4190

поведінкою, яку передбачає програміст. Розробник часто використо-
вує для тестування ( testing frameworks) при створенні в автоматиза-
ції запуску наборів тестів. На практиці модульні тести покривають
критичні і нетривіальні ділянки коду. Це може бути код, який підля-

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

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

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

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

Рисунок 10.1 – Графічне представлення циклу розроблення

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

писаний. (Якщо ж написаний тест пройшов, це означає, що або «но-
ва» функціональність вже існує, або тест має недоліки). Щоб написа-
106