Різниця в часі між розробкою з одиничними тестами проти відсутністю тестів

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

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

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

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

Чим пізніше ви тестуєте, тим більше коштує писати тести.

Чим довше живе помилка, тим дорожче її виправити.

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

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

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

Кожен рядок коду без тестів буде важче налагодити чи переписати.

Кожен тест, який ви пишете, потребуватиме часу.

Кожна помилка потребує часу, щоб виправити її.

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

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

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

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

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

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

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

Рой Ошерово у своїй книзі «Мистецтво тестування підрозділів», сторінка 200, зробив тематичне дослідження впровадження проектів однакового розміру з подібними командами (з розумом) для двох різних клієнтів, де одна команда робила тестування, а інша - ні.

Його результати були такими:

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

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

Результатами дослідження було збільшення часу розвитку між 15% -35% (що ніде не перевищує показник 2x, який часто цитують критики TDD) та зменшення щільності дефектів перед випуском з 40% -90% (! ). Зауважте, що всі команди не мали попереднього досвіду роботи з TDD, тому можна було припустити, що збільшення часу може принаймні частково віднести до навчання, і, таким чином, знизиться ще більше з часом, але це не було оцінено дослідженням.

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

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

Справа в тому, що я недостатньо хороший кодер, щоб просто працювати з кодом, як тільки він збирається. Коли я пишу / змінюю код, я повинен запустити код, щоб переконатися, що він робить те, що я думав, що робить. В одному проекті це, як правило, виглядало так:

1. Змініть код
2. Складіть додаток
3. Запустити додаток
4. Увійдіть у додаток
5. Відкрийте вікно
6. Виберіть елемент у цьому вікні, щоб відкрити інше вікно
7. Встановіть у цьому вікні кілька елементів керування та натисніть кнопку

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

Тепер, що робити, якщо я використовую одиничні тести? Тоді процес виглядає більше:

1. Напишіть тест
2. Запустіть тести, переконайтеся, що він не працює очікуваним способом
3. Написати код
4. Знову запустіть тести, побачите, що він проходить

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

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

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

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

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

http://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf

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

Для мене в більшості проектів написання одиничних тестів означає, що я швидко виконую роботу на 25%. Так, навіть включаючи час для написання тестів.

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

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

Проблема загострюється у міру збільшення віку проекту: адже щоразу, коли ви додаєте нову функціональність та / або кожен раз, коли ви рефакторируете існуючу реалізацію, вам слід повторно протестувати те, що раніше було протестовано, щоб переконатися, що воно все ще працює. Отже, для довготривалого (багаторічного) проекту вам може знадобитися не тільки перевірити функціональність, але повторно протестувати його 100 і більше разів. З цієї причини ви можете скористатися автоматизованими тестами. Однак для ІМО це досить добре (або навіть краще), якщо це автоматичні системні тести, а не автоматизовані тестові одиниці.

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

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

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

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

Кращим питанням може бути:

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

Навчання - це двоступеневий процес: навчіться робити це досить добре, а потім навчіться робити це швидше.

Деякі аспекти, які слід врахувати, не згадані в інших відповідях.

• Додаткова вигода / додаткова вартість залежать від досвіду написання одиничних тестів
  • в моєму першому проектному тестовому проекті додаткові витрати збільшилися вдвічі, тому що мені довелося багато навчитися, і я зробив багато помилок.
  • після 10-річного досвіду роботи з tdd мені потрібно на 25% більше часу на кодування, щоб заздалегідь написати тести.
• з більшою кількістю tdd-модулів все ще є необхідність у ручному-gui-тесті та інтеграції-тестуванні
• tdd працює лише після початку.
  • застосування tdd до вже існуючого, дорослого проекту є дорогим / складним. Але ви можете замість цього застосувати регресійні тести.
• Автоматизовані тести (одиничні тести та інші види тестів) вимагають constrace const для того, щоб вони працювали.
  • створивши тест за допомогою копіювання та вставки, можна зробити тестовий код-основне дорогоцінним.
  • З ростом досвіду тестовий код стає більш модульним і легшим у обслуговуванні.
• З ростом досвіду ви отримаєте відчуття, коли варто створити автоматизовані тести, а коли ні.
  • Наприклад, не існує великої вигоди для простих опробовувачів / сеттерів / фантиків
  • я не пишу автоматизовані тести через gui
  • я дбаю про те, щоб бізнес-леді можна було протестувати

Підсумок

Починаючи з tdd, важко досягти стану "більше користі, ніж витрат", якщо ви перебуваєте в "обмеженому часом робочому середовищі", особливо якщо є "розумні менеджери", які говорять вам "позбутися дорогого, марного тестування матеріалів "

Примітка: під "одиничним тестуванням" я маю на увазі "модулі тестування ізольовано".

Примітка: маю на увазі під "регресійним тестуванням"

• написати якийсь код, який створює деякий вихідний текст.
• написати деякий код «тестування регресії», який підтверджує, що результат генерації ist все ще однаковий.
• тест регресії повідомляє вас про зміну результату (що може бути нормальним або індикатором для нової помилки)
• ідея "регресійного тестування" схожа на затвердження
  • ... зробив огляд результатів і підтвердив, що вони не змінилися.

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

Якщо не писати тести, то багато, як мати кредитну карту; ми, як правило, витрачаємо більше або пишемо більше коду. Більше коду має більше помилок.

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

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

Існувала довга історія ради програмістів, що просували TDD та інші методології тестування, я не згадую їх аргументи і погоджуюсь з ними, але ось додаткові речі, які слід врахувати, що повинні трохи відтінити:

• Тестування не однаково зручно та ефективно залежно від контексту. Я розробляю програмне забезпечення в Інтернеті, скажіть, чи є у вас програма для тестування всього інтерфейсу ... зараз я програмую макроси Excel, чи варто мені реально розробити тестовий модуль у VBA?
• Написання та обслуговування тестового програмного забезпечення - це справжня робота, яка рахується в короткостроковому періоді (окупається в більш тривалому періоді). Написання відповідних тестів - це також досвід
• Працюючи в команді і працюючи в самоті, не мають однакових вимог до тестів, тому що в команді вам потрібно перевірити, зрозуміти і повідомити код, який ви не писали.

Я б сказав, що тестування добре, але переконайтеся, що ви перевірите рано і перевірите, де виграш.

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

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

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

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

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

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

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

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

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

Просто для доповнення попередніх відповідей: пам’ятайте, що тестування не є самою метою. Мета тестів полягає в тому, щоб ваша програма поводилася так, як очікувалося в еволюції, у несподіваних контекстах тощо.

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

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

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