Разработка, управляемая тестами - убедите меня! [закрыто]

30

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

  1. Для каких проектов вы используете разработку через тестирование? Вы используете его только для проектов выше определенного размера?
  2. Я должен использовать это или нет? Убедить меня!
Casebash
источник
3
У меня так много проблем, просто написание тестов. Дошло до того, что я просто проверил все вручную.
TheLQ
Посмотрите на этот вопрос: stackoverflow.com/questions/301693/…
systempuntoout
1
@TheLQ ... попробуйте сказать моему клиенту, что с моим программным обеспечением для управления полетом все в порядке, потому что я провёл ручную проверку кода :-)
Эндрю

Ответы:

32

Хорошо, некоторые преимущества для TDD:

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

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

Fishtoaster
источник
10
«Тестируемый дизайн почти всегда лучше дизайна» - я думаю, что главная причина этого в том, что тестируемый код, как правило, модульный и с упрощенными зависимостями.
Скиллдрик
«Всем нравится иметь тесты, но немногие любят писать их». - это правда? Кажется, было бы интересно подумать о хороших тестах, попытаться отключить тестируемое программное обеспечение.
DarenW
3
@ DarenW- Я не знаю о тебе, но я предпочел бы заставить вещи работать, чем сломать их. Тем не менее, кто - то делает думать так , как вы предлагаете это Хелла-ценная в качестве тестера. В мире не хватает качественных парней QA.
Fishtoaster
Я получаю 403 Запрещенную ошибку на LNK к этому PDF
Нейл N
Обновленный до того, что, я уверен, был тем же самым pdf (это было пару лет назад)
Fishtoaster
11

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

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

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

Paddyslacker
источник
6

(Отказ от ответственности: я почти не занимаюсь интерфейсом, поэтому не могу обсуждать TDD для интерфейсов.)

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

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

Фрэнк Шиарар
источник
1
  • Всякий раз, когда ваш клиент может быть поставлен более эффективно (он, возможно, будет иметь хорошее отношение к тестам - и это по крайней мере сократит обсуждение в конце проекта)
  • Всякий раз, когда потребуется больше времени, чтобы ваши со-разработчики были проинформированы о ВСЁ в коде, чем прилагать усилия для создания теста - и это быстрее, чем вы думаете
Tobiasopdenbrouw
источник
-1

Какая? Нет отрицательного ответа !?

Отказ от ответственности: я не против юнит-тестирования. Когда люди говорят «TDD», я предполагаю, что они имеют в виду «звучащую болезнью» версию, в которой они пишут тесты, прежде чем они пишут код для 80-100% всего кода, который они пишут.

Я бы сказал:

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

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

  • Это кушает много времени. Я ударил случайные ошибки. Я не бью так много, что кажется, что стоит ставить перед каждой новой вещью, которую я пишу, тест на это. Поймать проблемы, где они могут произойти. Обрабатывайте ошибки так, чтобы их было легко диагностировать. Validate. Тест в ключевых точках перекрытия / узкого места. Но для того, чтобы кричать вслух, не проверяйте каждый последний получатель и установщик на что-то, что, вероятно, не должно было бы иметь их во-первых.

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

  • Сбой макропроекта: кодовая база моей текущей работы пронизана интерфейсами, которые никогда не используются более одного раза, и массовыми нарушениями базового принципа DRY, которые я окончательно начал понимать, когда понял, что люди пишут для тест-фреймворков и тестируют в генеральный. Тестирование не должно приводить к тупой архитектуре. Нет, на самом деле, нет ничего более масштабируемого или достойного предприятия для копирования и вставки 20 файлов, а затем только внесения существенных изменений в два из них. Идея состоит в том, чтобы разделить проблемы, а не разделять их по центру Грубая и бессмысленная абстракция обойдется вам дороже, чем 95% покрытия.

  • Это действительно популярно, и многим людям это действительно нравится. Если это не является достаточной причиной, чтобы хотя бы переоценить и / или проверить дерьмо любой технологии перед внедрением, выучите некоторую паранойю.

Эрик Реппен
источник
Баховщики читают только заголовок Q, а не его содержимое.
Эрик Реппен
1
Я понизил голос и прочитал все это. многие из указанных вами недостатков на самом деле устранены в самых основных книгах по TDD. TDD не означает «просто напишите как можно больше тестов WET non-SOLID, сколько сможете, и никогда не думайте о дизайне». Я думаю, что этот ответ - несправедливое искажение TDD. если ваше приложение становится беспорядочным, потому что люди копируют и внедряют ужасные дизайны, тогда это проблема дизайна. TDD - это просто рабочий процесс, и вы не обращаетесь к нему.
Сара