Должен ли я использовать TDD?


40

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

Я пытаюсь выяснить, должен ли я изучить Test Driven Development (TDD) и реализовать его в этом приложении.

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

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

40

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

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

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

+3

TDD отлично подходит для библиотечных процедур - таких как манипуляции с строками или даты - которые должны работать должным образом и могут быть небольшими. 04 авг. 112011-08-04 09:51:32

  0

Важно учитывать преимущества хорошего проекта TDD. Это может увеличить вашу способность получить качественный, ремонтный, сложный продукт из двери. Он также превосходит вас как разработчика и напрямую влияет на ремонтопригодность и гибкость продукта. Это добавляет ценность проекту и позволяет ускорить и упростить исправление/улучшение с течением времени. 17 май. 162016-05-17 14:46:26


25

Помните: единственный плохой тест - это тот, который вы не выполняете.

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

Но какой-нибудь логики вы можете выполнить за кулисами? Да, вы должны проверить это.

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

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

+5

+1: Просто сделайте это. «не научитесь достаточно хорошо» - это способ предотвратить прогресс, требуя «достаточно хорошо», прежде чем начать. Просто запустите! 27 май. 092009-05-27 18:53:17

  0

@ S.Lott: Именно! 27 май. 092009-05-27 18:59:09

+2

Помните: единственный плохой тест - это тот, t execute. Напоминает мне о http://www.youtube.com/watch?v=l1wKO3rID9g :) 27 май. 092009-05-27 19:49:23

+1

Хорошие моменты. Думаю, мне просто нужно это сделать и посмотреть, как это происходит. Это действительно единственный способ узнать что-то Спасибо 27 май. 092009-05-27 20:00:05

+4

Я не могу согласиться с: «единственный плохой тест - это тот, который вы не выполняете». Возможно, худший тест - это тот, который * появляется *, чтобы проверить что-то, но не делает, давая ложное ощущение безопасности. Другой вид плохого теста - это тест, который проверяет инфраструктуру, а не ваш код, например, тестирование, когда я назначаю значение целочисленной переменной, что присвоение произошло правильно. 08 янв. 102010-01-08 15:20:20

  0

TDD может быть только мастером, если вы практикуете его. ты тратишь тем лучше вы становитесь. Вначале вы чувствуете себя очень медленно, но по мере того, как вы делаете больше, вам становится лучше. 16 май. 132013-05-16 08:23:18

  0

слишком много тестов низкого качества могут замедлить автоматическое тестирование слишком много в сложных проектах, но мне тяжело это сделать. Возможно, некоторые новые автоматизированные продукты тестирования могут доставлять отчеты по истории результатов тестов, которые помогут мне позже. 17 май. 162016-05-17 14:50:04


4

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

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

-my .02

  0

Да! и TDD также позволяет вам включать концепции, в которых сборки и тесты выполняются автоматически и непрерывно по мере ввода нового кода! Проблемы могут быть обнаружены раньше, и прежде чем ваши коллеги отправятся в отпуск! 17 май. 162016-05-17 14:51:51


6

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


10

Обратите внимание, что TDD не касается тестирования; это процесс развития. Тестирование не выполняется для замены функции тестирования - это то, что определяет процесс dev.

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

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

  0

Обратите внимание, что могут быть доказательства того, что TDD не очень полезен в качестве процесса - успех может быть результатом (факта?) Того, что люди, которые находятся на передней стороне кривой, будут успешными независимо от того, какой процесс или недостаток процесса, который они используют. 05 авг. 112011-08-05 14:43:07


1

У вас есть компоненты, которые легко могут быть подвергнуты тестированию? Можете ли вы создать приложение как набор компонентов, подлежащих тестированию? На самом деле мышление придумывается при работе в среде TDD.

Его легко сказать «его приложение с графическим интерфейсом! Его невозможно отключить мои вещи»! Это может быть самоисполняющееся пророчество. Разумеется, вы не можете легко настроить макет всех ваших виджетов, но насколько ваша программа связана с тем, как ваши виджеты выложены? Вы можете перестать делать хороший TDD, потому что какой-то аспект слишком тесно связан с макетом ваших виджетов графического интерфейса или слишком тесно связан с чем-то еще, что нелегко унифицировать. Остановитесь и бросьте вызов себе - это действительно так? Могу ли я разделить и модулизовать код, чтобы он мог быть лучше изолирован от этих частей системы? Уместно ли это сделать (оправдывают ли затраты на уловку?). Не принимайте карт-бланш, что его невозможно только потому, что ваше программное обеспечение связано с не-совместимыми компонентами.


4

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

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

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


14

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

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

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

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

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

GUI-тестирование сложно, но не невозможно. Рассмотрим технологии тестирования веб-интерфейса, такие как Selenium, WebDriver и Watir, которые могут программно использовать веб-интерфейс. Легко также злоупотреблять этими инструментами, выполняя только дорогостоящие сквозные тесты с их использованием. А гораздо лучше подходит для абстрагирования вашего слоя пользовательского интерфейса, чтобы его можно было тестировать изолированно, независимо от вашей бизнес-логики. Вы не хотите, чтобы тестирование пользовательского интерфейса выполнялось и выполнялось в базе данных.

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

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

  0

Спасибо за ваш ответ 27 май. 092009-05-27 20:53:13


3

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


1

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

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


1

Калеб. Я хотел создать сайт, который был создан для помощи в обучении TDD дома. Вы учитесь лучше, если не находитесь под давлением. Просто google для «tdd-problems», и вы его найдете.

  0

Спасибо, я проверю! 01 июн. 092009-06-01 18:09:59


1

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

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

Вот пример каждого ...

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

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


3

Мысль я хотел бы резюмировать и прокомментировать некоторые из приведенных выше комментариев:

  1. Да TDD о Design. Речь идет не о тестировании.
  2. Не знаете, почему QA участвовали в разработке дизайна Джорджа. Похоже, они задавали автоматизированные тесты. Как отметил Тим, это процесс развития.
  3. Кевин, вы сказали «пропустите тестирование». Еще раз. TDD - это дизайн, это НЕ о тестировании. OK Вы можете пропустить дизайн, но готовое приложение будет ошибкой и неприемлемым.
  4. Рошан отметил, что «исполняемая спецификация того, что должен делать ваш компонент». Это означает полную актуальную документацию. Когда вы новичок в проекте, вы можете быстро добираться до скорости, вы можете точно увидеть, что хотел сделать оригинальный разработчик. И, как сказал Джон, вы можете внести изменения в код и убедиться, что ничего не сломано.

0

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

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

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

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

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

Некоторые хорошие ката можно найти here


-2

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

+1

Что такое вход? разве это не просто философия, и вы не внесли сколько-нибудь значимого вклада, чтобы ответить на сам вопрос? 18 мар. 162016-03-18 12:47:43