Негативний досвід TDD [закрито]

Яка негативна сторона вашого досвіду TDD? Чи вважаєте ви дитячі кроки (найпростіший виправлення, щоб зробити тест зеленим) дратівливими і марними? Чи вважаєте ви тести без значення (коли тест має сенс спочатку, але в остаточному впровадженні перевіряє ту ж логіку, що й інші тести)? тощо.

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

Будемо вдячні за посилання на статті, що описують негативні сторони TDD (Google наповнений позитивними та часто фанатичними статтями).

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

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

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

Це інтерв'ю Річака Хікі ( автор Clojure ) містить таке. Я відчуваю 100% співчуття:

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

Ще одна аналогічна заява Дональда Кнута в інтерв'ю Coders at Work , скопійована звідси :

Сейбель: Якщо говорити про практичну роботу, то в середині роботи над «Мистецтвом комп’ютерного програмування» ви взяли те, що перетворилося на десятирічну перерву, щоб написати свою систему набору тексту TeX. Я розумію, ви написали першу версію TeX повністю від комп'ютера.

Кнут: Коли я писав TeX спочатку в 1977 та 78 роках, я, звичайно, не мав грамотного програмування, але у мене було структуроване програмування. Я написав це у великий зошит з довгих рук, олівцем. Через півроку, переживши весь проект, я почав друкувати в комп’ютер. І здійснив налагодження в березні '78 року, поки я почав писати програму в жовтні 77 року. Код, який знаходиться в архівах Стенфорда - це все олівцем - і, звичайно, я б повернувся і змінив підпрограму, коли дізнався, що це має бути. Це була система першого покоління, тому було можливо багато різних архітектур, і їх потрібно було відкинути, поки я деякий час не жив з нею і не знав, що там є. І це була проблема з куркою-яйцем - ви не могли ввести шрифти, поки не мали шрифтів, але тоді не могли мати шрифти, доки не зможете набрати шрифти. Але структуроване програмування дало мені уявлення про інваріанти та знання того, як зробити чорні скриньки, які я міг би зрозуміти. Тому я мав впевненість, що код спрацює, коли я нарешті його налагоджую. Я відчував, що заощаджую багато часу, якби зачекав півроку, перш ніж щось тестувати. Я мав достатньо впевненості, що код був приблизно правильним.

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

Кнут: Правильно.

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

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

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

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

Я збираюся тут вийти на кінцівку і з жорстокою чесністю заявити, що це буквально ритуальна трата часу. (У більшості ситуацій.)

Я купив книгу про Unit Testing, в якій також обговорювалося TDD, і, хоча я згоден з перевагами UT, через сто годин випробування TDD я відмовився від неї з безлічі причин. Я тут щось перехресне повідомлення , але TDD:

1. Не краща документація, ніж реальна документація.
2. Не вловлює помилок чи регресій .
3. Це насправді не робить мої конструкції кращими, ніж вони в кінцевому підсумку, якщо я застосую якісь концепції функціонального програмування та компонування .
4. Час, який можна краще витратити на перегляд коду чи полірування документації та технічних характеристик.
5. Дає менеджерам помилкове почуття безпеки, коли вони бачать список із сотні зелених іконок.
6. Підвищує продуктивність при впровадженні алгоритмів з обмеженими відображеннями вводу-виводу.
7. Ви незграбні в тому, що ви можете знати, що ви робите в результаті TDD, але ви не заробляєте розуміння того, чому це працює так добре, чому ваші дизайни виходять так, як вони роблять.

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

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

У культурному відношенні TDD показує симптоми ритуальної практики. Він їде на вину; це заохочує процедуру щодо розуміння; у ньому є багато доктрин та гасел ("підробка", поки ти це зробиш "- це справді досить тривожно, якщо поглянути на це об'єктивно). Визначення у Вікіпедії слова "ритуал" насправді є досить підходящим:

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

Додамо, ще одне занепокоєння щодо TDD, яке я помітив:

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

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

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

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

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

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

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

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

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

Як великий шанувальник TDD, я іноді бачу ці недоліки

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

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

• Якщо ви перебуваєте під тиском часу, у вас може виникнути спроба усунути зламані тести (або прокоментувати їх), а не виправляти їх. Таким чином ви втрачаєте інвестиції в тести

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

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

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

Поняття мужності та посилення циклів зворотного зв'язку, про які він згадує, також є, на мій погляд, ключовими для продуктивності.

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

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

ТДД ревнощі.

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

ІМО, найбільша їхня брехня полягає в тому, що TDD приведе вас до порятунку кращою розробкою алгоритму. Дивіться знаменитий солюку Solver, написаний в TDD: тут , тут , тут , тут і тут

І порівняйте це вирішувач судоку Peter Norvig, зроблений не за допомогою TDD, а за допомогою старомодної інженерії: http://norvig.com/sudoku.html

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

TDD має деякі переваги:

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

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

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

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

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

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

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

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

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

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

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

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

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