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

Ответ 1

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

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

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

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

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

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

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

Ответ 4

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

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

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

Ответ 5

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

Ответ 6

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

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

-my.02

Ответ 7

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

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

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

Ответ 8

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

Ответ 9

Думаю, что я бы обобщил и прокомментировал некоторые из приведенных выше замечаний:

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

Ответ 10

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

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

Ответ 11

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

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

Ответ 12

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

Ответ 13

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

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

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

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

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

Ответ 14

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

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

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

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

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

Некоторые хорошие ката можно найти здесь

Ответ 15

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