Тестовая разработка - убедить меня! [закрыто

Question

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

1. Для каких проектов вы используете тестовые разработки? Вы используете его только для проектов выше определенного размера?
2. Я должен использовать это или нет? Убедить меня!

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

Answer 5

Какая? Нет негативного ответа!?

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

Я бы сказал:

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

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

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

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

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

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