Який ефект від створення тестових одиниць під час розробки вчасно, а також часу, витраченого на технічне обслуговування?

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

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

Мене цікавить вплив одиничних тестів на час та вартість розробки:

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

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

Існує кілька дуже цікавих досліджень з цього приводу. Прочитайте наступний документ:

Усвідомлення покращення якості завдяки тестовому розвитку: результати та досвід чотирьох промислових команд

Тут обговорюються статті та інші дослідження одного з її авторів, Nachi Nagappan : http://research.microsoft.com/en-us/news/features/nagappan-100609.aspx

Дослідження та його результати були опубліковані у статті «Реалізація покращення якості за рахунок тестових розробок: результати та досвід чотирьох промислових колективів Нагаппана та колег з досліджень Е. Майкла Максимілієна з дослідницького центру IBM Almaden; Тірумалеш Бхат, головний лідер розробки програмного забезпечення в Microsoft; та Лорі Вільямс з Державного університету Північної Кароліни. Дослідницька група виявила, що команди TDD створили код, який був на 60-90 відсотків кращим за щільністю дефектів, ніж команди, що не мають TDD. Вони також виявили, що командам TDD потрібно було більше часу, щоб завершити свої проекти - на 15–35 відсотків більше.

"За 12 циклів розвитку 35 відсотків - це ще чотири місяці, що є величезним", - говорить Нагаппан. "Однак, компроміс полягає в тому, що ви значно скорочуєте витрати на обслуговування після випуску, оскільки якість коду набагато краща. Знову ж таки, це рішення, які повинні приймати менеджери - де вони повинні приймати удар? Але зараз вони фактично мають кількісні дані для прийняття цих рішень ».

Крім того, Джейсон Горман був запропонований такий експеримент в цьому році на конференції Software Майстерності. Він намагався експерименту, створюючи ту саму програму, використовуючи TDD та підхід, що не є TDD, і він нещодавно веде блог про свої результати :

Протягом трьох ітерацій, середній час, необхідний для заповнення ката без TDD, становив 28м 40с. Середній час з TDD склав 25м 27с. Без TDD я в середньому зробив 5,7 пропуску (здавання на прийняття тестування). З TDD я в середньому зробив 1,3 проходу (за дві спроби вони пройшли перший раз, в одній знадобилося 2 проходу.)

Тепер, звичайно, це був дитячий експеримент. І не зовсім лабораторні умови. Але зазначу пару цікавих речей, все одно.

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

Чи є якась статистика, яка показує, на скільки годин зменшується обслуговування при проведенні (хороших) одиниць тестів?

З довідки зверху:

Результати тематичних досліджень свідчать про те, що щільність дефектів перед випуском чотирьох продуктів знизилася між 40% і 90% щодо аналогічних проектів, які не використовували практику TDD.