Недавно я немного читал о TDD и тому подобное, и пока я не совсем продаюсь. Я делаю много небольших проектов для хобби (только я), и я обеспокоен тем, что пытаюсь сделать TDD является излишним для такой вещи. Хотя я видел небольшие проекты с открытым исходным кодом, например, 3 разработчика, которые делают TDD. (хотя я видел несколько проектов с одним человеком, которые также делают TDD)
Итак, TDD всегда хорошо делать или на каком пороге имеет смысл использовать?
TDD светит в небольших проектах. Часто бывает намного легче придерживаться TDD в небольшом проекте, и это прекрасное время для практики и получения дисциплины, необходимой для отслеживания TDD.
По моему опыту более крупные проекты, как правило, являются теми, кто отказывается от TDD на каком-то пороге. (Я не предлагаю, чтобы это было хорошо).
Я думаю, что крупные проекты, как правило, отказываются от него по нескольким причинам:
Маленькие проекты могут иметь привычку превращаться в большие проекты, если вы не понимаете, тогда вы хотите, чтобы вы начали с TDD:)
Все имеет кривую с затратами и выгодами.
Игнорируя многие из "спорных преимуществ TDD", TDD стоит того, если ваша реализация будет достаточно часто меняться, что преимущество наличия автоматизированного набора перевешивает любые дополнительные затраты, которые могут быть задействованы в начальной развитие.
Из моего личного опыта я могу сказать следующее:
Я всегда нахожу такой смешной вопрос. Какая альтернатива? Написание кода, который вы компилируете и никогда не запускаете, чтобы проверить его правильность? Подождите, пока вы не начнете развертывание, чтобы узнать, работает ли ваш класс вообще?
Если бы у нас никогда не было практики, называемой TDD, или до того, как JUnit был изобретен еще в 1997 году, не было ли тестирования кода? Конечно, было. Итак, почему сейчас так важно, что у вас есть тестовые рамки, которые помогут вам в этом?
Даже небольшой проект в сжатые сроки не захочет ждать, пока производство не выяснит, работает ли оно. Напишите тесты.
Для любого проекта не обязательно, что "маленький", но я определяю "маленький" как менее одного класса.
Overkill? Не за что. В дополнение к основному преимуществу, которое является написанием кода, на который вы можете положиться, потому что вы подумали о том, как он может сломаться, вы будете более дисциплинированным и потенциально более продуктивным с развитием, основанным на тестах. Возьмите любую из книг прагматического программиста для подсказок и вдохновения.
Я бы воспользовался возможностью использовать TDD с небольшим проектом только для того, чтобы ваши ноги были мокрыми. Это был бы хороший опыт обучения, даже если вы осознаете это не для вас.
Что-то, что я слышал от одного из членов нашей локальной группы Agile, заключается в том, что она не находит TDD полезной для самых ранних этапов проекта, где вы в основном делаете быстрые эскизы, и вы не совсем уверены, что форма вещь еще взята. Но как только вы узнаете, как выглядят интерфейсы, вы можете начать использовать тесты, чтобы помочь вам определить их.
TDD - еще один инструмент, например документация, для улучшения четкости кода. Это важно, когда другим людям необходимо работать с вашим кодом, но многие из нас считают его очень полезным, когда оглядываются на наш собственный код. Когда-либо у вас был хобби-проект, который вы выбрали, после того, как некоторое время от него ушел, наткнулся на странный кусочек кода и задался вопросом: "Почему, черт возьми, я написал это?"
Я считаю, что это стоит для большинства проектов. TDD и последующее регрессионное тестирование позволяют вам не только определить, работают ли компоненты, когда вы их пишете, но и при введении изменений и рефакторинга. Если ваши тесты достаточно полные, вы можете освещать сценарии для редких/маловероятных краевых случаев и создавать/поддерживать более надежный код.
Переход вперед по жизненному циклу проекта, непрерывные циклы тестирования избавят вас от ручного повторения тестов и отрицают очевидную вероятность повторного их неправильного/неполного.
I и другие используют TDD для любого проекта, что больше, чем несколько строк кода.
Как только вы получите ошибку тестирования, трудно использовать TDD для чего-либо. Лично я обнаружил, что мой код несколько раз улучшался из-за TDD.
По моему опыту, в 90% случаев те, кто сомневается в преимуществах, не пробовали.
Попробуйте, скептически настроенный ум. Измерить то, что вы надеетесь получить от него, до и после.
Я могу указать на меньшее время потраченное/потраченное впустую исправление ошибок, обнаруженных в производстве. Я вижу/измеряю лучшую производительность (более быстрое время выхода на рынок), улучшает качество кода (по разным показателям), ближе соответствует требованиям (т.е. Меньше переделывает, поскольку требования не ясны) и т.д.
"Я лучше себя чувствую в проектах, использующих TDD, но тогда я" заражен тестированием ". Моральный дух разработчиков по проектам с использованием TDD обычно выше, как субъективное мнение.
Если вы не получите эти результаты, не используйте его. Если вам неинтересны эти результаты для их измерения, используйте TDD или нет, чтобы вы чувствовали себя лучше.
TDD имеет кривую обучения. Если вы не хотите прилагать усилия для серьезной попытки, не беспокойтесь.
Небольшой проект - отличный способ дать ему серьезную попытку, не рискуя.
Если вы считаете, что последующие ошибки, которые вы не ожидаете, могут произойти в результате написания кода, TDD имеет смысл.
Ну, на самом деле это не количество людей, которое является решающим фактором для TDD (по крайней мере, это то, что ваш вопрос имеет вид), но скорее размер проекта.
Преимущества TDD заключаются в том, что весь код, который вы разрабатываете, будет в значительной степени проверен на единицу. Таким образом, вы сможете сэкономить много хлопот при реорганизации позже. Конечно, это действительно необходимо, когда ваш проект имеет приличный размер.
Проект, разработанный с хорошим кодом OO, по своей сути хорошо подходит для тестирования, и, возможно, впоследствии может получить ориентированный на тестирование фокус в стиле разработки. На самом деле я бы сказал, что когда вы сталкиваетесь с новыми технологиями с ограниченным бюджетом, учитывая, что все TDD полностью необязательно.
Я бы сказал, что это полностью зависит от заданных временных рамок. Если у вас есть время потратить почти в два раза больше времени, чем обычно требуется, то идите. Но, на мой взгляд, скорость в наши дни является одним из самых важных факторов (для конкурентоспособных компаний).
Я думаю, что TDD стоит того, что не имеет значения (ДАЖЕ, если он один класс - так как сначала писать тесты могут помочь вам придумать более разумный дизайн).
Место, в котором я чувствую, что это может не понадобиться, - это когда вы строите проект, в котором вы не уверены, чего хотите, и вряд ли вы будете заботиться о ремонтопригодности. Я считаю, что нет никаких проектов, которые соответствуют этой категории на работе, но я обнаружил, что время от времени я разрабатываю личные проекты, в которых это так. В этих случаях я обычно изучаю новую структуру и понятия не имею, что я делаю с самого начала, поэтому мои тесты, скорее всего, со временем перевернутся по неправильным причинам, что снизит их ценность.
Тем не менее, я также признаю, что не использовать TDD стоит мне ремонтопригодность - как только я знаю, что делаю, я сразу возвращаюсь к red/green/refactor.