Нагадайте, що ж взагалі таке ваше «Test-Drive-Development»?
Це така техніка розробки програмного забезпечення, при якій вся розробка розбивається на безліч невеликих циклів: спочатку пишуться тести, які покривають бажану зміну, потім пишеться код, який ці тести проходить. Після цього проводиться рефакторинг цього коду, при необхідності пишуться нові тести. Якщо якісь тести ділянку коду не проходить, це виправляється.
Звучить якось дивно. А це точно ефективно?
Судячи з усього, так. По-перше, це дозволяє чіткіше зрозуміти, що, власне, потрібно писати. Є умова, яка повинна виконуватися після роботи коду - і крапка. Самі тести повинні формуватися на основі технічного завдання. Якщо в результаті написання тестів вони починають суперечити самі собі - це привід переглянути ТЗ.
По-друге, в результаті поділу завдань на менш об'ємні підзадачі, код стає помітно простіше і легким для читання. В ідеалі на один тест має припадати одне твердження (assert). До того ж поганий в оформленні код (наприклад, використовує глобальні змінні або Сінглтон) зазвичай так само складний в тестуванні, що стимулює розробника його не писати.
Але мені здається, що писати як зазвичай набагато швидше
Так, дійсно, спочатку застосування TDD буде віднімати зайвий час. Однак, це скоріше справа звички - з часом ви звикнете писати спершу тести, а лише потім код і, можливо, будете навіть вигравати в часі, адже процес розробки буде чітко структурований, вам доведеться спочатку вирішити питання «Що писати?», А лише потім "Як писати?". До того ж, витративши час зараз, ви виграєте час в майбутньому, сильно полегшивши собі підтримку продукту.
Чи завжди має сенс використовувати TDD?
Зрозуміло, немає. TDD не панацея. Наприклад, якщо розробка являє собою послідовність експериментів, коли немає чіткої впевненості в тому, що саме необхідно в підсумку, написання тестів стане швидше вантажем, який тягне команду назад.
