Яка реальна накладні витрати TDD, коли вся команда звикне до цього?

Який відсоток часу економиться та витрачається на виконання TDD.

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

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

Я чула десь 30-50% вашого часу написання одиничних тестів. Однак це не враховує витрачений час на написання цих тестів.

Який досвід кожного у цьому?

Уес

EDIT Що заощаджений час та вартість часу? У виправлення помилок та рефакторабливості?

Я чула десь 30-50% вашого часу написання одиничних тестів. Однак це не враховує заощадженого часу

На мій досвід, це більше 50%.

Після того, як ви написали тест, рішення має тенденцію надходити дуже легко. Тож я не думаю, що дивно витрачати 70% - 75% свого часу на тести, але ви витрачаєте набагато менше часу на написання «виробничого коду» (тестування коду) і практично не витрачаєте часу на відладчик .

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

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

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

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

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

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

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

TDD часто вимірюється до якості коду, а не часу та витрат. Однак з кращою якістю коду розробники та будь-які люди, що працюють з ними, можуть працювати краще (менше витраченого часу, менше витрат, щасливіше тощо). http://davidlongstreet.wordpress.com/2009/04/29/new-software-metric-wtfs-per-minute/

Написання тестів чудово допомагає автоматизувати перевірку функціональних та нефункціональних вимог. Одне відео, яке переконувало мене прийняти TDD (насправді BDD, TDD високого рівня): http://video.google.com/videoplay?docid=8135690990081075324#

• Написання функціональних тестів може допомогти виявити помилки / проблеми раніше на етапі розробки . Припустимо, у вас є велика база коду. З одиничними тестами / специфікаціями потрібно побачити лише "Усі тести пройшли" / "2 тести пройшли невдало, див. Рядок xyz". Вам потрібна лише команда розробників, яка займається розробкою та тестуванням. Без одиничних тестів / специфікацій вам доведеться вручну порівнювати надруковані висловлювання з очікуваними висловлюваннями і вручну відстежувати, які методи / класи мають помилки. Для цього вам, мабуть, потрібні дві окремі команди (розробники та тестери) .

• Письмові тести допомагають розробникам пояснити прогрес і проблеми, з якими стикаються.

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

З TDD ми раді дізнатися, коли:

• замовник вимагає зміни в вимогах (задовольняючи вимоги)
• виявлені кращі способи написання коду
• товариші команди мають пропозиції щодо вдосконалення коду
• ми повинні пояснити / передати наш код іншим людям

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

У нашому випадку я вважаю, що це близько 40%. Однак я не думаю, що ми пройшли фазу, коли це було більше ніж це. У нас є генератор коду, який випльовує як скелет коду, який розробляється розробниками, так і тестовий набір, який так само виходить. Більшість наших тестових зусиль насправді спрямовані на відстеження (або створення) відповідних тестових даних, щоб забезпечити повне охоплення.

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

короткотерміновими заходами буде ROI автоматизації тестів

наприклад: минулого тижня я зробив понад 1000 змін коду через зміну внутрішньої архітектури, запустив автоматизований тестовий набір і пішов спати.

тести займали 28 хвилин; всі вони пройшли. вручну виконання тих же тестів на прийняття 40+ зайняло б близько 6 годин.

ще один приклад: за попередню ітерацію я зафіксував один із тестових сценаріїв з непомітною помилкою, яку ручне тестування, ймовірно, не знайшло б (автоматичні тести виконують перевірки цілісності db, які ручні тестери майже ніколи не роблять). Мені довелося запустити тестовий сценарій приблизно 50 разів, перш ніж мені вдалося розібратися і виправити його. вручну виконання тестових сценаріїв займе близько 50 хвилин. Отже, це 41,6 людино-годинної праці, заощадженої за один день

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

але для мене рентабельність інвестицій автоматизованих тестів майже нескінченна

Це може багато допомогти обмежити тести одиниць на складні алгоритми, випадки, коли їх можна автоматично генерувати, та регресії.

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

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