Тестова розробка - переконайте мене! [зачинено]

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

1. Для яких проектів ви використовуєте тестові розробки? Чи використовуєте ви його лише для проектів вище певного розміру?
2. Потрібно я ним користуватися чи ні? Переконай мене!

Гаразд, деякі переваги TDD:

1. Це означає, що ви закінчите більше тестів. Кожен любить мають тести, але мало таких людей , як писати їх. Внесення тестових записів до потоку розвитку означає, що ви закінчите більше тестів.
2. Здача тесту змушує задуматися про достовірність вашого дизайну, а тестований дизайн майже завжди є кращим дизайном. Мені не зовсім зрозуміло, чому так трапляється, але мій досвід та досвід більшості євангелістів TDD, схоже, це підтверджують.
3. Ось дослідження, яке говорить про те, що, хоча TDD займає трохи більше часу, це хороша рентабельність інвестицій, оскільки ви отримуєте код більш високої якості, а отже, менше помилок для виправлення.
4. Це дає вам впевненість у рефакторингу. Чудово відчувати можливість змінити одну систему, не турбуючись про те, щоб порушити все інше, тому що вона досить добре покрита одиничними тестами.
5. Ви майже ніколи не отримуєте помилку повторення, оскільки кожен, кого ви знайдете, повинен пройти тест, перш ніж його виправлять.

Ви просили переконатися, тому це були вигоди. Дивіться це питання для більш збалансованого перегляду.

Роберт К. Мартін спочатку висловив ці моменти - я можу їх підкріпити з власного досвіду:

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

Я майже весь час займаюся TDD, чи працюю я над виробництвом чи ігровим кодом; У наші дні мені важко кодувати будь-який інший спосіб.

(Відмова: Я навряд чи будь-які речі інтерфейсу, тому я не можу обговорювати TDD для інтерфейсів користувача.)

Я використовую TDD майже в усьому, що я роблю, від тривіальних додатків до цілих стеків SIP.

Я не використовую TDD на застарілому веб-сайті PHP, який я взяв на себе. Мені боляче, що не маю тестів. І мені здається, що це сильно дратує випадкові пошкодження частин сайту, тому що у мене немає набору тестів регресії, який говорить про те, що я щось зламав. Клієнт не має бюджету, щоб я (а) писав тести для кодової бази і (б) в процесі робив код тестуваним в першу чергу, тому я просто мирився з ним.

• Кожен раз, коли ваш клієнт може бути забезпечений більш ефективно (вони, можливо, будуть добре пов'язані з тестами - і це принаймні зменшиться під час обговорення в кінці проекту)
• Кожного разу, коли потрібно тривати більше часу, щоб ваші співавтори інформували про ВСЕ ВСЕ в коді, ніж докладати зусиль для складання тесту - і це швидше, ніж ви можете подумати

Що? Немає негативної відповіді !?

Відмова від відповідальності: Я не є анти-блочним тестуванням. Коли люди кажуть TDD, я припускаю, що вони мають на увазі хвороботворну версію, де вони пишуть тести, перш ніж написати код на 80-100% всього коду, який вони пишуть.

Я б заперечив:

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

• Це допомагає людям ігнорувати справжню проблему. Під час виправлення однієї помилки перетворюється на гру whack-a-mol, де ще два спливаючих вікна вибухає архітектура. Фокус. Зосередьтеся на реальній проблемі. Бачити родимок перед тим, як їх треба побити, - це акуратно, але ви не повинні там бути в першу чергу.

• Їсть багато часу. У мене трапляються випадкові помилки. Я не впадаю в стільки, що, здається, варто приєднати кожну нову річ, яку я напишу, з її тестом. Ловіть проблеми, де вони, можливо, трапляться. Обробляйте помилки такі, що їх легко діагностувати. Підтвердити. Випробування в ключових точках перекриття / вузького місця. Але для того, щоб плакати вголос, не випробовуйте кожного останнього геттера і сетера в чомусь, що, мабуть, не повинно було мати таких в першу чергу.

• Фокус дизайну: Існує абсолютно ніякий спосіб, навіть хороший розробник не зможе написати найкращий код, який вони могли, коли вони також зосереджуються на тесті. Якщо це здається єдиним способом пристойного дизайну, я рекомендую ознайомитись із вищезгаданим про "зосередження уваги на реальній проблемі".

• Невдача в макро-дизайні: база даних коду на моїй теперішній роботі пронизана інтерфейсами, які ніколи не використовуються, і масовими порушеннями основного принципу DRY, які я нарешті почав розуміти, коли зрозумів, що люди пишуть для тестових рамок і тестують в загальний. Тестування не повинно призводити до дурної архітектури. Ні, насправді, немає нічого, що є якось більш масштабним або гідним для підприємства, щоб скопіювати та вставити 20 файлів, а потім лише змінити два з них. Ідея полягає в тому, щоб відокремити проблеми, а не розділити їх на середину. Чітка і безглузда абстракція обійдеться вам дорожче, ніж не матимете 95% покриття.

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