Якщо TDD стосується дизайну, навіщо мені це потрібно? [зачинено]

Гуру TDD все більше і більше говорять нам, що TDD - це не тести, а дизайн . Тому я знаю деяких розробників, які створюють дійсно чудовий дизайн без TDD. Чи повинні вони тоді практикувати TDD?

TDD не тільки допомагає мені прийти до найкращого остаточного дизайну, але допомагає мені потрапити туди за меншу кількість спроб.

У мене раніше було два чи три удари, перш ніж вирішити, який дизайн я вважав найкращим. Зараз саме той самий час витрачаю на написання тестів і зосереджую свою думку на правильному дизайні. І, як бонус, це залишає мене набір повторюваних тестів. Виграй!

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

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

Фундаментальна концепція - це набагато старша за TDD; проектування для тестабельності . Якщо ви суворо дотримуєтесь принципів SOLID , особливо принципу єдиної відповідальності , ви знайдете код, який дуже легко перевірити. З іншого боку, якщо ви, як правило, трохи недбалі в своєму дизайні, ви, ймовірно, знайдете процес написання одиничних тестів, щоб змусити вас робити це частіше, щоб уникнути розладу (а) з'ясування того, що потрібно пройти тестування та (b) витратити більше часу на встановлення залежностей, ніж на написання фактичних тестів.

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

Ви не можете знати, чи справді ви розробляєте тест-перевірку, якщо ви не пишете тести, а випадкові "тести на характеристики" лише 15% покриття коду не враховуються.

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

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

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

Я можу говорити лише зі свого досвіду. Для мене TDD приніс декілька речей, яких у мене раніше не було, в наборі інструментів стилів розвитку. Хоча, варто ще раз сказати, що TDD - це не рішення всього. Я завжди намагаюся розділити реалізацію готової розвідки та виробництва. TDD у фазі розвідки абсолютно не потрібен і навіть сповільнюється. З іншого боку, для виготовлення готового коду він приносить кілька переваг, які в короткостроковому та довгостроковому періодах є дуже цінними для психічного здоров'я розробників та карми проекту.

• TDD змушує задуматися перед тим, як реалізувати, що, як правило, є дуже хорошою практикою, яка заважає багато знімати і забувати рішення
• Це змушує мене думати невеликими частинами проблеми, змушуючи мене розбити рішення на невеликі шматочки, які підходять один до одного.
• Це змушує мене писати дуже роз'єднаний код, тому що коли мені доведеться заглушити / знущатися / підробляти щось, що не вкладається в проблему, я, природно, кидаю один "WTF, навіщо мені це робити, якщо мені не потрібно з цим зв'язуватися" . І це змушує мене краще зрозуміти зв’язки між речами.
• Це дає мені набір легко виконуваних перевірок свого коду, тому мені не доведеться проходити через болісний стиль "var_dump", "p", "pp", "echo" налагодження коду. Він просто повідомляє, що не так, коли не так. І якщо я ще не маю чека на це, просто питання додати простий тест, щоб перевіряти його знову і знову.
• Це робить мене впевненим, що мій код працює, якщо всі тести пройдуть перед тим, як розгорнути. Тоді замість того, щоб їсти свої нігті, я їду торт і п'ю каву і насолоджуюсь післяобіднім.
• Тести високого рівня дуже приємні в тих випадках, коли вам доведеться щось переробляти. Якщо мій модуль повинен надати деяку функціональність для зовнішнього світу, і я розробив функціональні / інтеграційні / огіркові тести, щоб довести, що він працює правильно, я буду дуже сміливим перетворювати пекло з цього коду. Кілька разів я стикався з кодом, у якому не було тестів, і мені потрібно було його переробляти. У цьому випадку на практиці було два шляхи. 1) скиньте код 2) пропустіть зміни та залиште його як є.

Є одна річ, яку TDD не виправляє. Якщо ви не знаєте, як будувати річ, яку ви будуєте, то TDD не створить рішення для вас. Потрібно мати грубу "конструкцію" або огляд проблеми та рішення. TDD змусить вас просто реалізувати його більш елегантним та ремонтованим способом з кодом вищої якості.

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

Можливо, існує багато способів досягти чудового дизайну, і безперечно існує безліч різноманітних тлумачень того, що є «великим» - або навіть «хорошим». Я підозрюю, що більшість TDDers не погодиться з вами щодо визначення - що якби ми подивилися на код, який ви вважаєте чудовим, ми вважали б його менш ніж великим. TDD спонукає нас до деяких дуже специфічних якостей, і ці якості рідко зустрічаються в не-TDD-коді.

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