Page 110 - 4190

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

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

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

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

тести достатньо повні. Вони виявляють будь-які непередбачені зміни
поведінки коду.
Тести можуть використовувати як документацію. Добрий код

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

відміну від тестів, не може сказати, що вона застаріла, такі ситуації,
коли документація не відповідає дійсності – не рідкість.

Недоліки розроблення через тестування

1. Головним недоліком TDD є те, що до нього важко звикнути.
2. Існують задачі, які неможливо (у крайньому випадку, на поточ-
ний момент) рішити тільки за допомогою тестів. Зокрема, TDD не до-

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

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

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

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

110