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

Який доказ є? Хтось насправді розробив одне і те ж програмне забезпечення з двома окремими командами, одна використовувала тестування одиниць, а інша ні, і порівнювала результати? Я сумніваюся в цьому. Чи просто я повинен це виправдати: "Подивіться це в Інтернеті, всі про це говорять, значить, це потрібно зробити правильно"?

Де є важкі докази, які переконують мирян у тому, що одиничне тестування варто докласти зусиль?

Так. Це посилання на дослідження Бобі Джорджа та Лорі Вільямса в NCST та ще одне Нагаппан та ін. Я впевнений, що є більше. Публікації доктора Вільямса про тестування можуть стати хорошою відправною точкою для їх пошуку.

[EDIT] Дві статті вище конкретно посилаються на TDD і показують на 15-35% збільшення початкового часу розробки після прийняття TDD, але зменшення дефектів перед випуском на 40-90%. Якщо ви не можете отримати повнотекстові версії, пропоную скористатися Google Scholar, щоб дізнатися, чи можна знайти загальнодоступну версію.

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

Чому?

Чому б не зробити це, тихо і розважливо. Вам не доведеться робити це все відразу. Це можна зробити невеликими крихітними шматочками.

Рамкове навчання займає дуже мало часу.

Написання одного тесту, лише одного, займає дуже мало часу.

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

Це все, що потрібно. Нікому не потрібно знати, що ти це робиш. Просто зроби це.

Я підходжу до цього іншого підходу:

Яка впевненість у вас, що ваш код правильний? Або що це не порушує припущення X, коли хтось із вашої команди змінює func1 ()? Без тестів, що зберігають вас "чесними", я не впевнений, що ви багато впевнені.

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

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

Ось де вона себе окупає: 1) Ви маєте впевненість у своєму коді та 2) Ви уловлюєте проблеми раніше, ніж ви могли б інакше. У вас немає QA хлопець сказати "ей, ви не турбувались межі перевірки функції xyz (), чи не так? Він не знайде цю помилку, тому що ви її знайшли місяць тому. Це добре для йому, добре для вас, добре для компанії і добре для клієнта.

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

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

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

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

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

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

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

Чому більшість одиниць тестування - це відходи Джеймса О Коплієна (худий і спритний гуру)

Більше про TDD, ніж про строго одиничне тестування, тут - посилання на Усвідомлення покращення якості завдяки розробці тестових розробок: результати та досвід роботи чотирьох промислових команд : Нагаппан, Е. Майкл Максимілієн, Тірумалеш Бхат та Лорі Вільямс. документ, опублікований групою Microsoft Empirical Software Engineering and Measurement (ESM) і вже згадуваний тут.

Команда виявила, що команди TDD виробляли код, який на 60% і 90% відсотків кращий (з точки зору щільності дефектів), ніж команди, що не мають TDD. Однак команди TDD потребували від 15% до 35% більше, щоб завершити свої проекти.

Ось чудовий і захоплюючий прочитання хлопця, який змінює свою компанію зсередини. Це не обмежується TDD. http://jamesshore.com/Change-Diary/ Зауважте, що він досить довго не переконував "лічильників бобів" і замість цього робив "партизанську тактику".

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

Вступ гостей редакторів: TDD - мистецтво безстрашного програмування [ посилання ]

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

Таблиця 1. Короткий зміст вибраних емпіричних досліджень тестово-розробленого: учасники галузі *

Таблиця 2. Підсумок вибраних емпіричних досліджень TDD: академічні учасники *

Вплив тестової розробки на зовнішню якість та продуктивність: метааналіз [ посилання ]

Анотація:

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

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

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

Ну, є кілька великих компаній, які вимагають від вас тестування одиниць, але якщо ви невелика компанія, то чому імітуєте великі?

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

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

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

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

Я просто почав його використовувати, коли мені щось нове було написати. Є стара приказка, що мені важко перекласти англійською, але:

Почніть з чогось такого простого, що ви не помітите, що це робите. Тренуючись на марафоні, почніть з ходьби 9 метрів і бігу на 1 метр, повторіть.

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

Редагувати : наприклад, як зазначалося, книга " Кодекс завершена " повідомляє про такі дослідження (параграф 20.3, "Відносна ефективність методик якості"). Але є також приватні дослідження в галузі консалтингу, що також доводить це.

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

Багато місяців тому я був свіжим випускником, працюючи над великим проектом VB6 і мав нагоду написати великий масив збереженого коду процедури. З підсистеми, яку я писав, вона складала приблизно 1/4 всієї кодової бази - близько 13000 LOC з 50K або близько того.

Я написав набір одиничних тестів для збережених процедур, але тестування блоку VB6 UI-коду реально неможливо без таких інструментів, як Rational Robot; принаймні, тоді не було.

Статистичні дані, отримані з оцінки якості, свідчили про те, що в цілій підсистемі було виявлено близько 40 або 50 дефектів, з яких два походять із збережених процедур. Це один дефект на 6500 рядків коду проти 1 на 1000-1200 або близько всієї частини. Майте на увазі також, що приблизно 2/3 коду VB6 був кодовим шаблоном для обробки помилок та ведення журналів, однаковий для всіх процедур.

Без занадто великого ручного розмахування ви можете приписати принаймні поліпшення на коефіцієнт дефектів в коефіцієнті дефектів.