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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я бы сказал:

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

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

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

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

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

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