Недостатки разработки через тестирование? [закрытый]

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

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

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

Его девиз был, осуществляют рефакторинг, осуществляют рефакторинг, осуществляют рефакторинг. Я понял, что осуществляют рефакторинг предназначенный 'не планирование заранее'.

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

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

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

, Когда код изменяется, необходимо изменить тесты также. С рефакторингом этого может быть большая дополнительная работа.

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

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

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

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

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

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

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

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

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

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

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

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

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

Dave Mann

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

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

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

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

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

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

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

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

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

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

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

, Как только разработчик оставляет или забывает причину, что тест возвращает одно определенное значение и не некоторого другого, Вы завинчены. TDD прекрасен, ЕСЛИ он соответственно документируется и окружается человекочитаемым (т.е. менеджер с заостренными волосами) документация, которая может быть упомянута через 5 лет, когда мировые изменения и Ваше приложение должны также.

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

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

• пригодность для обслуживания Теста:

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

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

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

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

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

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

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

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

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

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

, Если Вы работаете в компании, которая платит Вам KLOCs (или реализованные требования - даже если не протестированный) избегают TDD (или кодируйте обзоры, или парное программирование или Непрерывную Интеграцию, и т.д. и т.д. и т.д.).

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

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

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

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

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

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

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

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

Hope это помогает

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

Продажа его к управлению

TDD лучше всего сделан в парах. Для одного трудно сопротивляться желанию просто записать реализацию, когда Вы ЗНАЕТЕ , как записать если/еще оператор. Но пара сохранит Вас на задаче, потому что Вы сохраняете его на задаче. К сожалению, многие компании/менеджеры не думают, что это - хорошее использование ресурсов. Почему плата за двух человек для записи одной функции, когда у меня есть две функции, которые должны быть сделаны одновременно?

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

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

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

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

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

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

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

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

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

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

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

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

Так, (IMO) вкратце:

• количество времени, занятое для размышления (т.е. на самом деле grok'ing , тестирующий ).
• новое знание, требуемое знания, как записать тестируемый код.
• Понимание изменений в архитектуре, требуемых сделать код тестируемым.
• Увеличение Вашего навыка "Кодера TDD" при попытке улучшить все другие навыки, требуемые для нашего великолепного ремесла программирования:)
• Организация Вашей кодовой базы для включения тестового кода, не завинчивая производственный код. <час>

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

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

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

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

, Когда Вы начнете использовать насмешки, через некоторое время, Вы захотите начать использовать Внедрение зависимости (DI) и контейнер Инверсии управления (IoC). Чтобы сделать это, необходимо использовать интерфейсы для всего (которые имеют много самих ловушек).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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