Чи є райони, де TDD забезпечує високу рентабельність інвестицій та інші області, де рентабельність інвестицій настільки низька, що не варто їх дотримуватися? [зачинено]

Розробка тесту. Я розумію, подобається.

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

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

Програми, над якими я нещодавно працював, - це керовані даними веб-карти, побудовані на основі архітектури на основі Gui-> Presenter-> BusinessLogic-> Data Access Layer. Мій рівень доступу до даних перевіряється як ніхто. Шар ділової логіки досить добре перевірений. Презентатори тестуються лише у більш стабільних областях, а графічний інтерфейс, який змінюється щогодини, майже не має тестів.

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

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

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

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

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

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

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

Я думаю, що відмова від налагодження для тестового написання - дуже гарна угода.

Одне місце, де TDD дуже важко смокче, - це тестування поглядів у програмі MVC.

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

Мені подобається TDD для багатьох моїх тестувань, але це не єдиний інструмент в поясі програмістів.