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

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

Чи варті переваги TDD додаткового часу на розробку для невеликих команд з дуже чітким графіком?

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

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

Чим менша ваша команда, тим швидше ви можете отримати вигоду від TDD. Я бачив цю виплату в розмірі команди від 6 до 3.

Додатковий час розробки, про який ви говорите, може бути ілюзією .

Що відрізняє TDD від тестування стандартних одиниць, це те, що він використовується не просто для тестування.

TDD is a new way of developing software. Це один із найкращих способів, які я знаю.

Тому це не пов’язано з розміром вашого проекту. Ви отримаєте переваги з першого рядка коду .

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

поширене неправильне уявлення, дозвольте мені прокричати це:

ТЕСТИ В ТДД ДЛЯ ОСОБЛИВОСТІ

EOM.

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

Існує чудова книга про TDD, «Мистецтво тестування одиниць» ( офіційний сайт ), де є приклади в .net з версією Java на творах. Хороша частина полягає в тому, що є цілі глави, що розглядають такі питання, як "Інтеграція тестування підрозділу в організацію" - Глава 8 та "Робота зі застарілим кодом" - Глава 9. Хоча я не є експертом у цій галузі (поки :-)) На основі свого досвіду я вважаю, що це хороший вихідний пункт.

Щоб отримати відповіді, вам потрібно отримати кілька питань:

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

2. Як часто редакція коду, що видається прямо вперед, перетворює код або додає нову функцію, порушує щось, очевидно, не пов’язане? Знову ж таки, при хорошому тестовому покритті це може бути зменшено.

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

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

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

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

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

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

Підсумок - більш повільний розвиток, але мало дефектів, тим менше часу на виправлення помилок.

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

У розвитку, орієнтованому на поведінку, ви підходите до своїх квитків по-іншому: ви сідаєте з діловою людиною і працюєте з ними, щоб визначити поведінку, яку повинен мати цей фрагмент функціональності. Я описую це у записі у своєму блозі (назва посади: Написання поведінки ).

Сидячи з діловою людиною чи ким-небудь, допоможе вам і їм краще зрозуміти, що система повинна зробити, щоб усі були задоволені цим функціоналом. Що потрібно зробити, щоб можна було прийняти процес QA, який у вас є.

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

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

TL; ДР: Розвиток, орієнтований на поведінку, може швидко вдосконалитись, оскільки він орієнтований на клієнта. На мене, начебто, тестова розробка стосується тестування внутрішніх даних кодової бази, про які "ніхто" не піклується та дає менш очевидні переваги для бізнесу. (Розвиток поведінки, що рухається, має негайне зміни в вашому обличчі: інженери раптом мають набагато більше часу на зустріч із "замовником" або бізнес-аналітиком, щоб спробувати досягти цього права - що слід сприймати як хорошу справу ". , вони мають зустріч щодо Feature X, це означає, що на цьому фронті є прогрес! ")