Объясните TDD простыми словами

Question

Я просматривал StackOverflow, когда столкнулся с этим вопросом. Здесь автор упоминает свой стиль отладки:

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

• Я заканчиваю большой скрипт,
• Комментируйте все, кроме части, которую я хочу проверить
• Выполнить скрипт

и в одном из ответов другой пользователь говорит, что запрашивающий неверно отлаживает:

Ваша последовательность кажется мне совершенно обратной. Вот как я это делаю:

1. Я пишу тест на функциональность, которую хочу.
2. Я начинаю писать скрипт, выполнять биты и проверять результаты теста.
3. Я проверяю, что я сделал для документирования и публикации.

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

Можете ли вы объяснить TDD и его преимущества более простым способом?

Answer 1

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

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

• Я заканчиваю [раздел a] большого скрипта,
• Я пишу тест, который попадает только в ту область, которую я считаюпроблематично
• Выполнить тесты

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

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

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

Answer 2

В трех словах сохраните свои тесты.

Многие хорошие программисты тестируют на ходу, но они не сохраняют свои тесты. Они просто пишут небольшие кусочки кода, чтобы проверить свой код во время его написания. Перейдите от «test» как глагол (например, я проверял код) к «test» как существительное (например, вот тест для кода).

TDD - это нечто большее, но это хорошее начало.

Answer 3

Вот что вам кажется эффективным:

• Я заканчиваю большой скрипт,
• Комментируйте все, кроме части, которую я хочу проверить
• Выполнить скрипт

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

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

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

Answer 4

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

По сути, процесс такой же, как описанный выше человек:

1. Написатьтест - протестируйте необходимый вам функционал (но пока не существует)
2. Напишите небольшой фрагмент кода - заполните достаточно, чтобы сделать тест, который вы только что написалиpass
3. Repeat - вернитесь к шагу 1, пока не получите все необходимые функции

Часто это означает написание теста, который ссылается на объект,затем написание определения для этого объекта.Затем написание теста, который использует метод для этого объекта, а затем написание самого метода.Вы работаете с очень короткими интервалами, переходя от тестирования к кодированию (короткое = секунды с точностью до минуты с обеих сторон).

Философия TDD заключается в том, что вам нужно 100% (в идеале) покрытие тестами,Логически, если вы хотите писать тесты, у вас есть возможность написать их до или после того, как вы фактически закодируете функциональность.Преимущества выполнения этого перед написанием кода:

• Вы на самом деле тестируете свои тесты, поскольку они должны провалиться (когда вы их пишете), а затем проходят (когда вы пишете свой код)
• Вы гарантируете, что у вас всегда МНОГО тестового покрытия
• Когда вы идете на рефакторинг, вы знаете, что у вас много тестового покрытия, чтобы убедиться, что вы не делаете глупостей (это самое большое преимущество, которое я вижу,так как вы много раз работали над старым кодом, о котором забыли все тонкости)

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

Answer 5

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

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

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

Как говорится, я не хардлайнер TDD. В некоторых ситуациях я предпочитаю писать модульные тесты после написания реализации. Это проще, чем TDD, когда я работаю с новой технологией и не знаю, как выглядит желаемый результат, пока я его не реализовал (например, объект ViewResult в ASP.NET MVC).

Answer 6

Я не могу объяснить это в надлежащих терминах, но я могу вам сказать, что в целом TDD позволяет разработчику сосредоточиться на ФАКТИЧЕСКИХ требованиях задачи.Это равносильно другому методу, заставляющему требования быть очень конкретными и подробными.Как только тест полностью завершен, выполняется любой код, который успешно завершает тест.Период.Конец разработки для этой задачи.

Обязательно ли это более или менее эффективно, чем сделать это другим способом?Я так не думаю, в идеальном мире.Но большинство из нас не живут в идеальном мире.Так что, по моему мнению, если единственным человеком, который может представить требование каким-либо образом со 100% точностью, является создатель теста, то он работает нормально.Программисты не тратят время на гадание, что делать, они не пишут для условий, которые не могут возникнуть и т. Д.

Я сторонник TDD, но должен признать, что никогда не был в организацииэто сделал.

Answer 7

Я следую первому способу делать вещи.

Так же, как и многие другие

... второй способ ... кажется очень неэффективным способом ведения дел.

Все новые и разные вещи кажутся неэффективными.Привыкайте к тому, что все остальные неправы, а вы правы.

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

Можете ли вы объяснить TDD и его преимущества более простым способом?

Да.

TDD более эффективен, потому что этоболее эффективным.

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

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

Или вы можете написать тест и написать наименьший код, который пройдет тест эффективным способом.

Answer 8

Вам следует написать модульные тесты:

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

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

Answer 9

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

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

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