Недостатки разработки, основанной на испытаниях?

Ответ 1

Несколько недостатков (и я не утверждаю, что нет никаких преимуществ - особенно при написании основы проекта - это сэкономит много времени в конце):

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

Ответ 2

Если вы хотите сделать "реальный" TDD (прочитайте: сначала проверьте с помощью красных, зеленых, шагов рефакторинга), вам также нужно начать использовать mocks/stubs, если вы хотите протестировать точки интеграции.

Когда вы начнете использовать mocks, через некоторое время вы захотите начать использовать инъекции зависимостей (DI) и контейнер Inversion of Control (IoC). Для этого вам нужно использовать интерфейсы для всего (у которых есть много подводных камней).

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

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

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

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

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

Если вы читаете литературу TDD, всегда есть некоторые очень хорошие примеры, но часто в реальных приложениях вы должны иметь пользовательский интерфейс и базу данных. Здесь TDD становится очень тяжело, и большинство источников не дают хороших ответов. И если они это делают, он всегда включает в себя больше абстракций: макеты объектов, программирование на интерфейс, шаблоны MVC/MVP и т.д., Которые снова требуют больших знаний, и... вам нужно написать еще больше кода.

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

Ответ 3

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

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

Ответ 4

Я думаю, что самая большая проблема для меня - это ОГРОМНАЯ потеря времени, необходимая для того, чтобы "войти в нее". Я все еще нахожусь в начале моего пути с TDD (см. мой блог, чтобы узнать о моих тестовых приключениях, если вам интересно), и я буквально потратил часов, чтобы начать работу.

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

TBH, я с уважением не согласен с комментариями Джейсона Коэна о том, как сделать частные методы публичными, а не о том, о чем идет речь. В моем новом способе работы я не опубликовал больше методов, чем раньше. Однако он включает в себя архитектурные изменения и позволяет вам "горячо подключать" модули кода для упрощения тестирования всего остального. Вы не должны делать внутреннюю часть своего кода более доступной для этого. Иначе мы вернемся к исходной точке, где все открыто, где инкапсуляция в этом?

Итак, (IMO) в двух словах:

• Время, затрачиваемое на обдумывание (т.е. на самом деле утомительное тестирование).
• Новые знания требуют умения писать тестируемый код.
• Понимание архитектурных изменений, необходимых для обеспечения возможности тестирования кода.
• Повышайте свои навыки работы с "TDD-Coder", одновременно пытаясь улучшить все остальные навыки, необходимые для нашего славного ремесла программистов :)
• Организация вашей кодовой базы для включения тестового кода без использования вашего рабочего кода.

  ---

PS: Если вам нужны ссылки на позитивы, я задавал и отвечал на несколько вопросов, проверьте мой профиль.

Ответ 5

В те немногие годы, что я тренировал Test Driven Development, я должен сказать, что самыми большими минусами являются:

Продажа его руководству

TDD лучше всего делать парами. Во-первых, трудно сопротивляться стремлению просто написать реализацию, когда вы KNOW, как написать инструкцию if/else. Но пара будет держать вас на задаче, потому что вы держите его на задаче. К сожалению, многие компании/менеджеры не считают, что это хорошее использование ресурсов. Зачем платить за двух человек, чтобы написать одну функцию, когда у меня есть две функции, которые необходимо выполнить одновременно?

Продажа его другим разработчикам

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

Поддержание тестового кода вместе с производственным кодом

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

Написание тестов, чтобы вы покрывали все (покрытие на 100% кода)

В идеале, опять же, если вы придерживаетесь методологии, ваш код будет проверен на 100% по умолчанию. Как правило, мысль, я в конечном итоге с покрытием кода вверх 90%. Обычно это происходит, когда у меня есть архитектура стиля шаблона, и база тестируется, и я пытаюсь разрезать углы и не тестировать настройки шаблона. Кроме того, я обнаружил, что, когда я сталкиваюсь с новым барьером, с которым я раньше не сталкивался, у меня есть кривая обучения при его тестировании. Я соглашусь писать некоторые строки кода старым способом skool, но мне очень нравится иметь это 100%. (Наверное, я учился в школе, учился.)

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

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

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

Ответ 6

В вашем первом проекте TDD есть две большие потери, время и личная свобода

Вы теряете время, потому что:

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

Вы теряете личную свободу, потому что:

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

Надеюсь, что это поможет

Ответ 7

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

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

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

Ответ 8

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

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

Ответ 9

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

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

Ответ 10

Если ваши тесты не очень тщательны, вы можете попасть в ложное чувство "все работает" только потому, что вы проходите тесты. Теоретически, если ваши тесты проходят, код работает; но если бы мы могли написать код совершенно в первый раз, нам не нужны тесты. Мораль здесь заключается в том, чтобы убедиться, что вы сделаете проверку здравомыслия самостоятельно, прежде чем называть что-то полное, не просто полагайтесь на тесты.

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

Ответ 11

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

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

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

Ответ 12

Я столкнулся с несколькими ситуациями, когда TDD делает меня сумасшедшим. Чтобы назвать некоторые:

• Поддерживаемость тестового случая:

  Если вы находитесь в большом предприятии, у вас есть много шансов, что вам не нужно писать сами тесты, или, по крайней мере, большинство из них написано кем-то еще, когда вы входите в компанию. Время от времени приложение время от времени меняется, и если у вас нет системы, такой как HP Quality Center, чтобы отслеживать их, вы можете сходить с ума в кратчайшие сроки.

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

• Сложность автоматизации тестирования:

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

  Кроме того, вы потратите время на отладку кодов, которые помогут вам поймать ошибки. На мой взгляд, большинство этих ошибок возникают из-за отказа тестирующей команды отразить изменения приложения в тесте автоматизации script. Изменения в бизнес-логике, графическом интерфейсе и других внутренних возможностях могут привести к тому, что ваши скрипты перестанут работать или выполняются неуверенно. Иногда изменения очень тонкие и трудно обнаружить. После того, как все мои сценарии сообщают об ошибке, потому что они основывали свои вычисления на информации из таблицы 1, тогда как таблица 1 теперь была таблицей 2 (поскольку кто-то менял местами имена табличных объектов в коде приложения).

Ответ 13

Самая большая проблема - люди, которые не знают, как писать правильные модульные тесты. Они пишут тесты, которые зависят друг от друга (и они отлично работают с Ant, но потом внезапно сбой, когда я запускаю их из Eclipse, просто потому, что они работают в другом порядке). Они пишут тесты, которые не тестируют ничего в частности - они просто отлаживают код, проверяют результат и меняют его на тест, называя его "test1". Они расширяют возможности классов и методов, просто потому, что им будет проще писать для них единичные тесты. Код модульных тестов ужасен, со всеми проблемами классического программирования (тяжелая связь, методы длиной 500 строк, жестко закодированные значения, дублирование кода) и ад для поддержки. По какой-то странной причине люди рассматривают модульные тесты как нечто уступающие "реальному" коду, и они вообще не заботятся о своем качестве.: - (

Ответ 14

Вы теряете возможность сказать, что вы "сделали", прежде чем тестировать весь свой код.

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

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

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

Вы теряете свободу крепко соединять свои модули.

Вы теряете возможность пропустить написание низкоуровневой проектной документации.

Вы теряете стабильность, которая приходит с кодом, который все боятся изменить.

Ответ 15

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

Ответ 16

Самым большим недостатком является то, что, если вы действительно хотите сделать TDD должным образом, вам придется много неудаться, прежде чем вы добьетесь успеха. Учитывая, сколько программных компаний работает (доллар за KLOC), вас в конечном итоге уволят. Даже если ваш код быстрее, чище, проще в обслуживании и имеет меньше ошибок.

Если вы работаете в компании, которая платит вам KLOC (или выполняемые требования, даже если они не протестированы) держаться подальше от TDD (или обзоров кода, или программирования пар или непрерывной интеграции и т.д. и т.д. и т.д.).

Ответ 17

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

Ответ 18

Он воспринимается медленнее. Долгосрочный, что не соответствует истине с точки зрения скорби, это сэкономит вам дорогу, но вы закончите писать больше кода, поэтому, возможно, вы проводите время на "тестирование не кодирования". Это неправильный аргумент, но вы спросили!

Ответ 19

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

Подумайте об этом, вы, скорее всего, закончите разработку конкретных тестовых примеров, поэтому вы не сможете стать творческими и начать думать "было бы круто, если бы пользователь мог делать X, Y и Z". Поэтому, когда этот пользователь начинает все возбуждать потенциальные холодные требования X, Y и Z, ваш дизайн может быть слишком жестко ориентирован на уже определенные тестовые примеры, и его будет сложно настроить.

Это, конечно же, меч с двойным острием. Если вы потратите все свое время на проектирование для всех мыслимых, воображаемых, X, Y и Z, которые пользователь может когда-либо захотеть, вы неизбежно никогда ничего не добьетесь. Если вы что-то сделаете, то для любого (включая вас самого) невозможно будет понять, что вы делаете в своем коде/дизайне.

Ответ 20

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

Ответ 21

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

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

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

Дейв Манн

Ответ 22

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

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

TDD - умение, так что младшие разработчики могут сначала сражаться (в основном потому, что их не научили работать таким образом).

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

Ответ 23

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

Ответ 24

• unit test - это больше кода для записи, таким образом, более высокие первоначальные затраты на разработку
• больше кода для поддержки
• требуется дополнительное обучение

Ответ 25

Хорошие ответы на все. Я бы добавил несколько способов избежать темной стороны TDD:

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

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

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

Ответ 26

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

При изменении кода вы также должны изменить тесты. С рефакторингом это может быть много дополнительной работы.

Ответ 27

Позвольте мне добавить, что если вы применяете принципы BDD к проекту TDD, вы можете смягчить некоторые из основных недостатков, перечисленных здесь (путаница, недоразумения и т.д.). Если вы не знакомы с BDD, вы должны прочитать введение Дэна Севера. Он подошел к этой концепции в ответ на некоторые из проблем, возникших в результате применения TDD на рабочем месте. Dan intro для BDD можно найти здесь.

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

Ответ 28

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

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

Ответ 29

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

Его девизом был рефакторинг, рефактор, рефактор. Я понял, что рефакторинг означает "не планировать вперед".

Ответ 30

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