Чи варто тестування одиниць або тестова розробка?

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

Схоже, написання тестів - це додаткова робота, яка дає людям милицю, коли вони пишуть реальний код, і може бути не дуже ефективною.

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

Крім того, чи є щось, що робить TDD особливо гарним для Scrum?

Коротка відповідь: Абсолютно позитивно.

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

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

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

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

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

Джерело зображення

Чи варто тестування одиниць або тестова розробка?

Так, це так . Дядько Боб (Роберт Мартін) розповів у презентації;

Щоб розробник довів, що його код працює краще, щоб написати тест і здати його, ніж кричати, співати чи танцювати про нього.

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

На ньому написано багато речей,

1. Ви несете відповідальність за те, щоб ця функція працювала. Напишіть тест. Просто зроби це.
2. Коли замінити модульні тести інтеграційним тестом

Чи пов'язані SCRUM, Unit тестування та TDD?

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

Чи є щось, що робить TDD особливо гарним для SCRUM?

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

Схоже, написання тестів - це додаткова робота, яка дає людям милицю, коли вони пишуть реальний код, і може бути не дуже ефективною.

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

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

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

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

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

Крім того, чи є щось, що робить TDD особливо гарним для SCRUM?

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

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

Мої причини тестування одиниць також включають:

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

Дає відчуття прогресу.

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

Забезпечує додатковий рівень документації (особливо якщо ви правильно коментуєте свої тести).

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

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

Чи варто тестування одиниць або тестова розробка?

Безумовно, так (див. Інші відповіді)

[Це] насправді гарна ідея і варті зусиль і часу?

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

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

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

Якщо ви робите TDD, код автоматично перевіряється.

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

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

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

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

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

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

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

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

Щодо підходу червоно-зеленого рефактора до TDD, я вважаю, що це трохи нудно. Але у кожного своє.

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

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

Насправді існує один тип тестування, який я виявив загальновизнаним і, на мою думку, зрештою марним. А саме тестування на основі GUI, наприклад, за допомогою селену, веб-драйвера, Watir або Arquillian. Ось так ми отримуємо 7-годинний цикл побудови, а не 5-хвилинний цикл збірки на моїх проектах TDD.

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

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

Отже, у вас є вибір. Ви можете зробити дизайн та документацію, застосувавши TDD - це єдиний відомий і перевірений метод виготовлення такої документації на основі мого 10-річного досвіду розробки. Або ви можете піти в політику.