Page 108 - 4190

як “роби простіше дурнику” (keep it simple, stupid, KISS ) і “вам це не
знадобиться” (you ain’t gonna need it, YAGNI). Дизайн може бути чис-
тішим і зрозумілішим, при написанні лише того коду, який необхід-
ний для проходження тесту. У літературі також пропонують, принцип

«підроби, поки не зробиш» ( fake it till you make it). Тести повинні пи-
сатися для функціональності, яка тестується. Вважається, жо це має
дві переваги. Це помагає переконатися, що додаток придатний для

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

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

ревірки слід приступити до реалізації нової функціональності. Цей
прийом, відомий як “червоний/зелений/рефленторинг”, називають
«мантрою розробки чараз тестування». Під червоним тут вважаєть-

ся ті, що не пройшли тестування, а під зеленим – ті, що пройшли.
Відпрацьована практика розроблення через тестування привикли
до створення техніки «розроблення через приймальне тестування»

(Acceptance Test-driven development, ATDD), в якому критерії, що опи-
сані замовником, автоматизуються в приймальні тести, які потім ви-
користовуються в звичайному процесі розроблення через модульне

тестування (unit test-driven development, UTDD). Цей процес дозволяє
гарантувати, що додаток задовольняє сформульовані вимоги. При
розробленні через приймальне тестування, команда програмістів ско-
нцентрована на чіткій задачі: задовольнити приймальні тести, які ві-

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

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

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

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

108