Page 22 - 4787
P. 22
немає тестів, помилку можна виявити через певний час, коли з кодом
працювати буде набагато складніше. Добре протестований код легко
переносить рефакторинг. Впевненість уу тому, що зміни не зламають існуючу
функціональність, надає впевненості програмістам і збільшує ефективність їх
роботи. Якщо існуючий код добре покритий тестами, то програмісти будуть
почувати себе вільніше при внесенні архітектурних рішень, які повинні
покращити дизайн коду.
Розробка через тестування сприяє більш модульному, гнучкому коду і
коду, який можна розширювати. Це пов’язано з тим, що за такої методології
програмісту необхідно думати про програму, як про множину невеликих
модулів, які написані та опротестовані незалежно і лише потім з’єднані разом.
Це приводить до менших, більш спеціалізованих класів, зменшення зв’язаності
і біш чистих інтерфейсів. Використання mock-об’єктів також вносить вклад у
модуляризацію коду, осаільки вимагає наявності простого механізму для
перключення між mock- і звичайними класами.
Оскільки пишеться лише той код, який необхідний для проходження
тесту, автоматизовані тести покривають усі шляхи виконання. Наприклад,
перед використанням нового умовного оператора програміст повинен написати
тест, що мотивує додавання цього умовного оператора. В результаті отримаємо
при розробці через тестування тести достатньо повні. Вони виявляють будь-які
непередбачені зміни поведінки коду.
Тести можна використовувати як документацію. Читабельний код
розкаже про те, як він працює краще будь-якої документації. Документація і
коментарі в коді можуть застаріти. Це може збивати з толку програмістів, які
вивчають код. А оскільки як документація, на відміну від тестів, не може
сказати, то вона застаріла. Такі ситуації, коли документація не відповідає
дійсності – не рідкість.
Недоліки розробки через тестування.
1. Головним недоліком TDD є те, що до нього важко звикнути.
2. Існують задачі, які неможливо ( у крайньому випадку, на поточний
момент) рішити тільки за допомогою тестів. Зокрема, TDD не дозволяє
21
