Я должен использовать TDD?

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

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

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

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

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

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

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

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

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

-my .02

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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