TDD негативный опыт [закрыт]


95

Какова отрицательная сторона вашего опыта TDD? Считаете ли вы, что детские шаги (самое простое решение, чтобы сделать тест зеленым) раздражают и бесполезны? Считаете ли вы, что тесты без значения (когда тест изначально имеет смысл, но в финальной реализации проверяет ту же логику, что и другие тесты), критически важны для обслуживания? и т.п.

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

Был бы благодарен за ссылки на статьи, описывающие отрицательные стороны TDD (Google полон положительных и часто фанатичных статей).


10
Я предполагаю, что вы не услышите много честных ответов о негативном опыте людей, потому что TDD все еще находится в состоянии «раннего усыновления», и большинство людей, которые заинтересованы и преданы этому, недостаточно объективны, чтобы оцените это по его относительным достоинствам. Индустрии обычно требуется несколько лет, чтобы действительно установить долгосрочные последствия новых процессов и методов, и даже тогда трудно получить прямые ответы из-за отсутствия контроля. Хороший вопрос и удачи в получении полезных ответов!
Аарона

20
У вас проблемы с поиском негатива в интернете ?!
Эрик Уилсон

4
@Job (и, возможно, другие): не забудьте, что он спросил о TDD, а не о модульном тестировании. TDD! = Модульное тестирование.
n1ckp

2
Я испытываю желание ответить на этот вопрос, но я действительно не хочу начинать, потому что это займет половину моего дня.
Рей Миясака

2
Когда я обнаруживаю, что трачу достаточно времени на ошибки, кажется, что я могу потратить меньше времени на написание тестов для каждой отдельной вещи, которую я пишу до того, как напишу ее, я не приму TDD «первым делом все». Вместо этого я опущу голову от стыда и начну искать новую карьеру. Не об ошибках ты говоришь? Дизайн? Да. Вот и все. Это точно. И вы не узнали чертову вещь о надежном дизайне, предоставив себе сеть безопасности и лицензию на продолжение глупой работы. Отложите IDE и попробуйте прочитать свой код, если вы хотите обнаружить реальную проблему.
Эрик Реппен

Ответы:


95

Как и все, что попадает под баннер «Agile», TDD в теории звучит хорошо, но на практике не очень понятно, насколько он хорош (а также, как и большинство «Agile» вещей, вам говорят, что если вы не нравится, ты делаешь это неправильно).

Определение TDD не выгравировано в камне: такие ребята, как Кент Бек, требуют, чтобы некомпилируемый тест был написан до одной строки кода, а каждая отдельная строка кода должна быть написана, чтобы пройти неудачный тест. Передний дизайн минимален и все движетсяпо тестам. Это просто не работает. Я видел крупное корпоративное приложение, разработанное с использованием этой методологии, и я надеюсь, что это худший код, который я вижу за свою карьеру (он не за горами; и это несмотря на то, что над ним работают талантливые разработчики). Из того, что я видел, это приводит к огромному количеству плохо продуманных тестов, которые в основном проверяют, что происходят вызовы функций, что исключения генерируются, когда переменные равны нулю, и фальшивый фреймворк получает полную тренировку (whoop-de-whoop); ваш производственный код тесно связан с этими тестами, и мечта о постоянном и простом рефакторинге не появляется - на самом деле люди даже реже могут исправить плохой код из-за всех тестов, которые он сломает.

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


7
+1 «Проектирование испытаний на высоком уровне как часть фазы планирования - наряду с архитектурным дизайном» Для меня это звучит гораздо более разумно.
Стивен Джеурис

11
@Aaronaught Agile не значит , нет планирования, это означает , что только во время планирования.
Адам Яскевич

25
@ Adam Jaskiewicz: Мне нравится вещь "без предварительного планирования". Да ладно, планирование заранее по определению . Если вы не планируете заранее, но во время мероприятия вы не планируете вообще; Вы импровизируете. ;-)
CesarGon

34
@ Adam - "Люди действительно прыгают прямо в кодирование в первый день итерации?" эм да Это "ловкий" человек. В последнем месте, где я работал (и меня уволили за то, что я не был «проворным»), они выполнили весь 3-месячный цикл выпуска, не планируя ни одной строчки кода или одной страницы документации. И да, код был ужасен, и да, программное обеспечение было медленным, неуклюжим и глючным. В тот день, когда я присоединился, менеджер с гордостью сказал мне, что это «Самый проворный магазин в Лондоне». Они уверены, что были.

7
Можно добавить еще одну проблему: пока она проходит тест, она должна быть хорошей. Не берите в голову, что сам тест может быть ошибочным и поэтому вызывает ложные отрицательные и / или ложные положительные результаты. И, конечно же, требование «100% покрытия тестами» и всего, что имеет такое, идеально по определению, в результате чего появляются бесполезные тесты, которые на самом деле ничего не тестируют, а написаны исключительно для достижения 100% покрытия, код, который не документирован, потому что ваш счетчик покрытия учитывает комментарии как
открытый

67

Это ( Clojure автор) Рич Хикки интервью содержит следующее. Я чувствую себя на 100% сочувствующим:

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

Еще одно подобное заявление Дональда Кнута из интервью книги Coders at Work , скопированное отсюда :

Сейбел: Говоря о практической работе, в середине работы над «Искусством компьютерного программирования» вы взяли то, что превратилось в десятилетний перерыв, чтобы написать вашу систему набора текста TeX. Я понимаю, что вы написали первую версию TeX полностью подальше от компьютера.

Кнут: Когда я писал TeX первоначально в 1977 и 78 годах, конечно, у меня не было грамотного программирования, но у меня было структурированное программирование. Я написал это в большой тетради от руки, карандашом. Через шесть месяцев, пройдя весь проект, я начал печатать на компьютере. И сделал отладку в марте 78 года, когда я начал писать программу в октябре 77 года. Код для этого находится в архивах Стэнфорда - все это карандашом - и, конечно, я бы вернулся и изменил подпрограмму, когда узнал, что это должно быть. Это была система первого поколения, поэтому было возможно множество различных архитектур, и их пришлось отбросить, пока я некоторое время не жил с ней и не знал, что там было. И это была проблема курицы и яйца - вы не могли печатать, пока у вас не было шрифтов, но тогда у вас не могло быть шрифтов, пока вы не могли печатать. Но структурированное программирование дало мне идею инвариантов и умение создавать черные ящики, которые я мог понять. Так что я был уверен, что код сработает, когда я, наконец, отладлю его. Я чувствовал, что сэкономил бы много времени, если бы подождал шесть месяцев, прежде чем что-то тестировать. У меня было достаточно уверенности, что код был примерно правильным.

Сейбел: И экономия времени будет заключаться в том, что вы не потратите время на создание строительных лесов и заглушек для тестирования неполного кода?

Кнут: Верно.


24
Я думаю, что вы должны посмотреть на тип работы, которую вы делаете. Кнут и Хикки говорят о разработке новых (инновационных) приложений. Если вы посмотрите, где TDD популярен (широкая избыточная генерализация), то вы поймете, что большинство приложений, написанных в стиле TDD, уже имеют хорошо известную архитектуру.
Себастьян

4
Я понимаю, что означает Rich Hickey, но я хотел бы добавить следующее: мой опыт показывает, что когда вы пишете тесты, вам нужно по-настоящему задуматься о своем дизайне и подумать о том, как вы делаете свой код тестируемым, что в моем опыт, приводит к лучшему дизайну.
Никлас Х

3
Поскольку ОП требует отрицательного опыта с TDD, ни один из ваших примеров не кажется актуальным для этого вопроса, поскольку ни один из них не показывает пример TDD в действии.
Уинстон Эверт

5
@Michael Borgwardt: относительно легко добавить тесты в существующий, хороший дизайн, чтобы избавиться от ошибок в реализации. Но избавление от плохого дизайна часто означает полное переписывание. Таким образом, основная цель должна заключаться в правильном оформлении дизайна ; выполнение легче исправить позже.
Joonas Pulakka

4
Большинство бизнес-приложений не имеют преимущества написания и / или поддержки Дональдом Кнутом. Время жизни приложения обычно НАМНОГО дольше, чем его первичная разработка. Я бы хотел, чтобы люди заранее написали больше тестов для моего текущего проекта. Теперь обслуживание похоже на минное поле бесконечных регрессий.
Мэтт H

58

Мой негативный опыт с TDD был моим первым. TDD звучало для меня замечательно, я проводил тестирование годами и все еще думал о ужасах. Я хотел раздавить каждую ошибку, прежде чем она превратилась в сборку. К сожалению, использование TDD не гарантирует, что вы будете писать хорошие тесты. Фактически, моя первоначальная предрасположенность заключалась в написании простых тестов, которые генерировали простой код. Действительно простой код, содержащий мало абстракций. Действительно простые тесты, которые были переплетены с внутренними классами. И как только у вас будет несколько тысяч маленьких тестов, вы не почувствуете, что движетесь быстрее, если вам нужно изменить сотню из них, чтобы реорганизовать ваш код, чтобы использовать очень важную концепцию домена X.

У меня загорелся свет - TDD не является навыком тестирования. Это дизайнерский навык. Он может только привести вас к хорошему, простому, работоспособному коду с практикой и постоянным знанием направлений проектирования, в которых он вас ведет. Если вы пишете тесты ради покрытия кода, вы собираетесь создавать хрупкие тесты. Если вы пишете тесты, помогающие создавать абстракции, то это просто более строгий способ написания нисходящего кода. Сначала вы видите код с точки зрения вызывающего, что побуждает вас сделать его жизнь проще, а не отражать внутреннюю часть класса на его внешнем краю.

Я думаю, что TDD полезен, но я не догматичен в этом. Если эти «бесполезные испытания» затрудняют техническое обслуживание - удалите их! Я отношусь к тестам так же, как и к остальному коду. Если это можно изменить и упростить, сделайте это!

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


7
Вы прибили это в пункте 2.
Шелдон Варкентин

4
«Я не видел этого лично, но я слышал, что в некоторых местах отслеживается охват кода и количество тестов» Я жил в такой среде, и на самом деле ни один код никогда не был выброшен, потому что это могло привести к провалу теста. Пока я не начал отлаживать реальные тесты, которые были, и обнаружил, что у многих из них были такие серьезные недостатки, они заставляли код выдавать неправильные результаты для прохождения тестов. Именно тогда я придумал вопрос: «кто тестирует тесты», на который до сих пор у меня никогда не было удовлетворительного ответа от сообщества TDD. Юнит-тесты для юнит-тестов, кто-нибудь?
jwenting

@jwenting - И этот анекдот довольно хорошо поддерживает аргумент Рей. Я обнаружил, что аспект защиты от регрессии TDD на практике преувеличен, даже если это теоретическая идея. Тесты должны проводиться так, чтобы они поддерживались на том же уровне, что и рабочий код, чтобы он работал, и это немного неестественно для обработки непроизводственного кода таким образом - я вижу ту же «гниль кода» с аппаратными симуляторами, генераторами кода, и т.д. все время.
Стив Джексон

«Действительно простые тесты, которые были переплетены с внутренними классами» <- вот тут-то и возникла ваша проблема. Тестировать только на общедоступных интерфейсах. TDD! = UT
Стивен А. Лоу

2
@ StevenA.Lowe - я знаю это сейчас, но 9 лет назад это было не так ясно :) «TDD - это не навык тестирования»
Стив Джексон

41

Я собираюсь выйти на конечности здесь и заявить с жестокой честностью, что это буквально ритуальная трата времени. (В большинстве ситуаций.)

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

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

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

Конечно, если утверждают, что, делая вещи в стиле TDD, вы придете к проектам, которые могут легко работать с TDD, что ж, есть гораздо более быстрые способы достичь этого, а именно путем изучения концепций компонуемости. Там много ресурсов, даже много строгой математической теории (в основном в функциональном программировании, но также и в других областях). Почему бы не тратить все свое время на обучение TDD ?

В культурном отношении TDD демонстрирует признаки ритуальной практики. Это едет на вине; это побуждает процедуру к пониманию; у него тонны доктрин и лозунгов («притворяйся, пока не сделаешь» действительно вызывает тревогу, если смотреть на это объективно). Определение слова "ритуал" в Википедии на самом деле весьма уместно:

В психологии термин ритуал иногда используется в техническом смысле для повторяющегося поведения, систематически используемого человеком для нейтрализации или предотвращения тревоги; это симптом обсессивно-компульсивного расстройства.


Очень интересная перспектива: ритуал. В некоторых кругах также возникает ощущение, что приверженность программиста своему мастерству оценивается исключительно пропорционально его приверженности TDD.
yalestar

Я бы сказал, что в некоторых ситуациях это может улучшить дизайн, но в основном это когда дизайн должен быть очень модульным с очень четким и простым в использовании публичным интерфейсом. Написание тестов для него перед реализацией самой библиотеки в этих случаях может помочь устранить ошибки в общедоступном интерфейсе, а также усилить эту модульность.
jwenting

8
@jwenting Люди занимаются TDD, потому что они не знают, что делает конструкцию модульной, поэтому они никогда не смогут снять свои 35 "тренировочные колеса со своих 40" велосипедов. Создание модульного проекта - это всегда выполнимая задача, если вы понимаете концепции, потому что каждая дилемма в вашем проекте будет иметь управляемый размер из-за того, что она, по своей концепции, находится в процессе становления модульным. Я не согласен , что TDD эффективен при нагнетании модульности, но я не согласен , что один должен быть вынуждены в создании модульных конструкций. Модульная конструкция - это отлично обучаемое и обучаемое умение.
Рей Миясака

@jwenting Что касается удобства использования публичных интерфейсов, среди практиков TDD есть две точки зрения по этому вопросу, обе из которых нежелательны: делать все публичным, чтобы его можно было протестировать, или оставлять вещи частными, если их все равно не следует тестировать. , Первая заставляет ненужные детали реализации быть доступными для конечных пользователей (которые могут быть использованы неправильно или эксплуатироваться), а вторая заставляет модульные тесты быть ближе к системным тестам. Конечно, вы можете использовать инструменты модульного тестирования для доступа к частным лицам, но в TDD нет особого смысла.
Рей Миясака

1
@Kall В этом интервью он говорит: «примерно на 15–35% больше времени», а не только на 15%, как вы его цитировали. Исследование также затрагивает только Java / C ++ / C # (возможно, C # 2 с учетом даты) - все языки с одной и той же императивной парадигмой ООП. Я, безусловно, более чем на 15% и, возможно, более чем на 35% более продуктивен в функциональном языке (и даже в C # 3), и я создаю гораздо меньше ошибок, пишущих код без сохранения состояния, составляемый код - те же самые ошибки, которые улучшаются при тестировании, потому что обе вещи решают одни и те же типы проблем. Другими словами, конечно, снижение ошибок на 60-90%, но по сравнению с чем ?
Рей Миясака

18

Чтобы добавить, еще одна проблема с TDD, которую я заметил:

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

Я знаю парня, который является менеджером и технически скучным, когда одержим TDD. Для него это было настолько волшебным, что он верил, что это принесет волшебные решения всех проблем его плохо спроектированного программного обеспечения с наименьшим количеством поддерживаемого кода. Не сказать, что случилось с этим проектом - он с треском провалился в его руках, в то время как все его тестовые шкафы были зелеными. Я предполагаю, что TDD помог ему получить некоторую статистическую информацию, такую ​​как «99/100 моих дел зеленые» и т. Д., И это стало причиной его одержимости, поскольку он никогда не сможет оценить качество или предложить улучшения в дизайне.


2
Похоже, что PHB ад! Это напоминает мне о компаниях, которые внедряют бонусные схемы - то, что происходит, конечно, так это то, что разработчики вместо того, чтобы сосредоточиться на качественном коде, сосредотачиваются на том, чтобы соответствовать требованиям бонуса. Неизбежно вы получите более хрупкий код. (Здесь также есть аналогия с текущим банковским кризисом :-))
TrojanName

Ну, TDD - это не метод управления проектами, поэтому неудивительно, что ваш подражатель-менеджер потерпел неудачу. С другой стороны, я не чувствую себя менее креативным, я даже чувствую себя более креативным, потому что разработка тестов автоматически дает мне другой взгляд на мой код. Однако я согласен с тем, что основное внимание должно уделяться производственному коду, и тесты не должны испортить хорошую программную архитектуру.
Alex

Покрытие кода - это проблема модульного тестирования, а не TDD. TDD заботится только о функциях и тестах через общедоступные интерфейсы.
Стивен А. Лоу

14

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

В любом случае рефакторинг - отличное упражнение, но он необходим для приведения кода в тестируемое состояние. И после этого шага у меня нет сдержек и противовесов, чтобы посмотреть, не сломались ли мои изменения; кроме запуска приложения и изучения каждого варианта использования.

С другой стороны, добавление функций / исправление ошибок в проект TDD становится очень простым. По своей природе код, написанный с использованием TDD, обычно довольно не связан с небольшими кусочками для работы.

В любом случае, TDD является ориентиром. Следуйте по нему до точки, где вы обнаружите, что вы получите максимальную эффективность. Достойный тестовый охват и разделенный код, хорошо написанный код.


1
Если сложно написать модульные тесты, то обычно существует плохое разделение задач. Я не считаю это ошибкой TDD, если что-то быстро делает очевидными эти проблемы.
Том Керр

7
Это не негативный опыт с TDD, это негативный опыт с дерьмовым кодом.
Рей Миясака

13

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

При этом, если у вас есть фреймворк, такой как рельсы, где ваши архитектурные решения очень ограничены, этих проблем в принципе не существует

Еще одна проблема - когда вы слепо доверяете своим тестам. Правда - как и любой другой код - ваши тесты тоже могут иметь ошибки. Поэтому будьте так же критичны к своим тестам, как и к своей реализации.


2
Может быть, вы должны написать несколько тестов для ваших тестов! : p ...... Малыш, Малыш
Арен

+1 +1 +1 +1 (если бы у меня было 3 фиктивных аккаунта). Предложение № 2 очень проницательное и не содержит предвзятости подтверждения TDD, которая слишком распространена.
tgm1024

11

Как большой поклонник TDD я иногда вижу эти недостатки

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

  • Если вы испытываете нехватку времени, у вас может возникнуть желание устранить неработающие тесты (или закомментировать их) вместо того, чтобы их исправлять . Таким образом, вы теряете инвестиции в тесты


2
+1: «Искушение написать слишком много тестов ради почти 100% охвата кода.» не охватываются модульными тестами и могут быть легко найдены путем пошаговой отладки кода.
Джорджио

9

Мне еще не приходилось сталкиваться с несколькими сценариями в качестве разработчика игр, в которых TDD стоил того. И случай, в котором это было, был частью кода, который был чисто математическим по своей природе и нуждался в серьезном подходе для одновременной проверки огромного числа крайних случаев - редкая необходимость.

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

Простота - «Что самое простое, что могло бы сработать?»
Сообщение очень ясно. Учитывая требования на сегодня, разработайте и напишите свое программное обеспечение. Не пытайтесь предвидеть будущее, пусть будущее развернется. Это будет часто делать это очень непредсказуемым образом, делая ожидание слишком дорогой ценой ».

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


9
Проблема в том, что без модульных тестов вы знаете, что ваш беспощадный рефакторинг приводит к коду, который делает то же самое? По своему опыту я обнаружил, что в зависимости от проблемы у меня может быть меньше времени на написание тестов + кода, чем на написание кода самостоятельно! Причина в основном сводится к тому, что для некоторых задач я могу опробовать повторный множитель и выполнить повторное автоматическое тестирование гораздо быстрее, чем я могу проверить его вручную, что может значительно увеличить скорость итераций.
Марк Бут

6
Для игр очень часто можно увидеть результаты. Если их можно увидеть и казаться достаточно хорошими, они будут приняты, поскольку игра в любом случае должна быть субъективной. С другой стороны, принимая, например. В качестве примера Diablo 2, количество ошибок в боевых формулах показало, где TDD мог бы принести огромную пользу и сэкономить им огромное количество работы над патчами. Для очень четко определенных задач, таких как решение уравнений, и в тех случаях, когда они не могут быть оценены по визуальным результатам во время выполнения, TDD является обязательным условием для обеспечения правильности. Но это небольшая часть кода в большинстве игр.
инженер

Также стоит упомянуть, что из-за скорости, с которой запускаются симуляции, лучше наблюдать за переменными в реальном времени, на экране, во время работы сима, чем сидеть с миллионами строковых лог-файлов для просмотра постфактум.
Инженер

3
По моему опыту, юнит-тесты значительно упрощают рефакторинг .
Том Керр

1
@Nick Большой проблемой в игровой индустрии являются сроки, которые всегда - «мы должны были поставить пол года назад». Я думаю, что время играет против юнит-тестов в условиях ограниченного времени. В некоторых случаях это неправильное решение, но в большинстве случаев доставка без написания теста происходит быстрее. Зависит, действительно зависит ...
Кодер

7

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

Вероятно, это не помогает, что часто я единственный человек во всей компании, который знает, что такое модульное тестирование (TDD или другое) и почему это хорошо.


1
Вот тут-то и появляются мокинг-фреймворки. Создавайте экземпляры Fooс объектами Mock, а не напрямую, затем вы можете вызвать функцию, которую вы хотите протестировать, а затем проверить, что mock-функции вызывались с ожидаемыми вами функциями. Поддельные объекты - это активная технология, которая помогает разъединить модули и сделать их тестируемыми. Вот почему синглтоны злые, потому что вы часто не можете просто издеваться над ними. * 8 ')QuuxBaz
Марк Бут

7

Фанаты TDD.

Для меня они - лишь одна из длинной череды религиозных психов, стучащихся в мою дверь, пытающихся доказать, что мой способ ведения дел непоправимо нарушен, и единственный путь к спасению - это Иисус, Кент Бэк или Юнит-тестирование.

IMO, их самая большая ложь в том, что TDD приведет вас к спасению лучшего дизайна алгоритма. Смотрите знаменитый Солдуку Солвер, написанный в TDD: здесь , здесь , здесь , здесь и здесь

И сравните его. Решатель Peter Norvig sudoku сделан не с использованием TDD, а с использованием старомодной техники: http://norvig.com/sudoku.html


Смотри, мы могли бы спорить об этом. Но у меня слишком много работы, так как я окончил университет Fullsail по специальности игровой дизайн. Основываясь на моих курсах и моей очень сложной работе, я могу сказать, что TDD действительно превосходит безумную построчную (отсутствие дизайна) разработку ленивых программистов. Послушайте, я бы этого не сказал, но это правда: большинство разработчиков, которые пошли в обычную университетскую программу CS, в основном не закончили обучение, те немногие, которые подавляющим большинством, не занялись разработкой программного обеспечения, и, кроме того, многие из них едва успевают , построчно. У университета Fullsail есть
Зомби

полный курс по разработке, управляемой тестами, и это действительно выводит разработчиков на правильный путь (в отличие от реализации связанного списка в c ++).
Зомби

Ссылки не работают, чувак!
lmiguelvargasf

Это много лет спустя, но @Zombies, посмотрите в «Уклон подтверждения». Многое из того, что всех нас преподают в CS в колледже, относится именно к этой категории. Взгляните на
безрассудное

Lol человек я троллинг ... я написал, что так давно я забыл об этом маленьком жемчужине.
Зомби

5

Если вы используете TDD из этих «фанатичных» статей, у вас будет неправильное ощущение безопасности, что ваше программное обеспечение не содержит ошибок.


1
Можете ли вы получить какое-либо иное чувство, кроме знания того, что для данного набора входных данных ваше программное обеспечение возвращает заданный набор выходных данных?

пока вы понимаете, что tdd - это процесс разработки, а не золотое правило для решения любых проблем, это нормально. Но большинство людей, которые предлагают использовать этот процесс, забыли, что это процесс разработки, и, как и у любого другого процесса, есть светлая сторона и темная сторона. Они говорят всем, что если вы будете использовать tdd, у вас будет свободное программное обеспечение для ошибок, потому что вы будете использовать test для охвата каждой функции. И обычно это не правильно. В лучшем случае будут тесты для каждого случая (или, по крайней мере, функции), но тесты - это программы (у которых есть ошибки), и это только тесты черного ящика.
Дайний

4

У TDD есть некоторые преимущества:

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

TDD о долгосрочных инвестициях. Усилия окупаются, когда вы переходите в режим обслуживания вашего приложения, и если приложение не планируется достичь этого уровня, вы никогда не сможете вернуть инвестиции.

Я считаю, что TDD красно-зеленый цикл с детскими шагами похож на контрольный список для самолета. Досадно и утомительно проверять каждую вещь в самолете перед взлетом, особенно если это тривиально просто (шаги ребенка TDD), но было обнаружено, что это повышает безопасность. Помимо проверки, что все работает, это, по сути, сбрасывает самолет . Другими словами, самолет перезагружается перед каждым взлетом.


3
Точка 2 преимущества может быть достигнута с помощью простых модульных тестов без подхода TDD. Выгода 1, которую вы должны делать в любом случае. (Сосредоточение внимания на API) Все еще вполне возможно создать дрянной API с использованием TDD, но да, вы гарантированно, что он будет работать (для письменных тестов).
Стивен Джеурис

2
Вопрос не касался преимуществ TDD. На этот счет уже есть множество других вопросов.
Аарона

1
@aaronaught, я обращаюсь к его болевым точкам.

Ответы должны ответить на вопрос .
Аарона

1
@aaronaught, тогда напиши некоторые из них.

3

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

Что меня раздражает в TDD, так это то, что в нем много правил или рекомендаций. Поскольку это все еще довольно новое, мы, как большинство из нас, начинаем в TDD. Так что то, что хорошо для некоторых из нас, может не работать для других. Что я хочу сказать, так это то, что не существует настоящего «неправильного или правильного» способа выполнения TDD: есть способ, который работает для меня - и моей команды, если она у меня есть.

Поэтому до тех пор, пока вы пишете тесты - до или после рабочего кода на самом деле не имеет значения ИМХО - я не уверен, что тестирование действительно означает, что вы должны следовать всем рекомендациям, которые изложены прямо сейчас, поскольку они еще не доказали, что они идеальное решение для каждодневной работы. Если вы найдете лучший способ написания тестов, вы должны опубликовать его в блоге, обсудить его здесь или написать статью об этом. Таким образом, примерно через десять лет мы могли бы поделиться достаточным опытом, чтобы определить, какое правило TDD можно считать хорошим или нет в определенной ситуации.


+1 Отличный комментарий. Это действительно не должно быть ни единственно верным путем, ни каким-либо другим способом.
пифоновый

3

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


1
Обычно вторая попытка даст вам более глубокое понимание проблемы, чем первая попытка, TDD или нет.
wobbily_col

3

Я обнаружил, что TDD работает плохо, когда речь идет о новых системах. Я разработчик видеоигр, и недавно использовал TDD для создания системы, которая использует несколько простых способов поведения для создания реалистичного движения объекта.

Например, есть поведения, ответственные за то, что вы уводили вас из опасных зон разных типов, и те, которые ответственны за то, что вы перемещали вас к интересным областям разных типов. Объединение результатов каждого поведения создает заключительное движение.

Внутренности системы были легко реализованы, и TDD был полезен для определения того, за что должна отвечать каждая подсистема.

Однако я столкнулся с проблемами, когда речь зашла о том, как поведенческие взаимодействия взаимодействуют, и что более важно, как они взаимодействуют с течением времени. Часто не было правильного ответа, и хотя мои первоначальные тесты проходили, QA могла продолжать находить крайние случаи, когда система не работала. Чтобы найти правильное решение, мне пришлось повторить несколько различных вариантов поведения, и если я обновлял тесты каждый раз, чтобы отразить новые варианты поведения, прежде чем проверять их работу в игре, я мог бы снова и снова выбрасывать тесты снова и снова. Поэтому я удалил эти тесты.

Возможно, мне следовало бы провести более сильные тесты, в которых были бы обнаружены крайние случаи, обнаруженные QA, но когда у вас есть такая система, которая работает на вершине многих систем физики и геймплея, и вы со временем сталкиваетесь с поведением, это становится чем-то вроде кошмар, чтобы точно указать, что происходит.

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.