TDD и модульное тестирование для коротких проектов с небольшими командами?

Question

Является ли TDD хорошим подходом для небольших и коротких проектов, выполняемых небольшими командами до 4 человек? Это действительно выгодное усилие?

А как насчет модульного тестирования? TDD подразумевает модульное тестирование, но не наоборот. Разве не будет достаточно модульного тестирования, проводимого время от времени в течение жизненного цикла разработки проекта, до разумного охвата кода?

Answer 1

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

Итак, вы можете утверждать, что TDD лучше всего подходит для небольших и коротких проектов, потому что в итоге вы пишете только тот код, который необходим для прохождения тестов, и ничего больше. Таким образом, снижая стоимость. Кроме того, при внесении изменений позднее вы получаете уверенность в тестах и ​​коде.

Следующее небольшое замечание, которое я хотел бы отметить, заключается в том, что многие проекты начинаются с малого и с короткого. Эти временные решения могут стать стратегической платформой для развития (в случае успеха).

Answer 2

Недавно я прочитал хорошее сообщение в блоге от Szymon Pobiega под названием Если вы не делаете TDD… .Я действительно рекомендую взглянуть на это.Это потому, что я немного скептически отношусь к TDD и отношу его к большим привычкам жизненного цикла разработки, как к окончательному решению для безопасности ваших проектов, вне зависимости от характера проекта.Мне нравится этот фрагмент:

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

Он ссылается на сессию Дана Севера с НДЦ 2012 .

Answer 3

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

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

Предположим, вам нужно написать приложение, которое печатает имя компьютера, на котором запущено приложение. Сначала вы пишете юнит-тест:

[Test]
public void ProducedMessage_IsCorrect()
{
    AreEqual(BusinessLibrary.ProduceMessage(), System.Environment.MachineName);
}

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

public string ProduceMessage()
{
    return "MyComputer";
}

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

Итак, какой-то мудрый член вашей команды меняет код на правильную форму, и вы продолжаете.

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

Answer 4

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

Только один пример: TDD определяет, что вы сначала выполняете свои тесты. Это подразумевает, что вы думаете о цели, которую хотите достичь, прежде чем приступить к реализации. Это приводит к лучшему коду.

Answer 5

Ответ ДА! И по следующей причине. Представьте себе следующий сценарий. Вы и ваша команда проекта создали отличное приложение и решили запустить его в производство. Через некоторое время к вам приходит пользователь и говорит: «Эй, ребята, я нашел ошибку в вашем приложении, не могли бы вы ее исправить? Конечно, вы говорите «да», исправьте ошибку, и пользователь счастлив. Только через некоторое время он возвращается, говоря, здорово, что вы исправили проблему, но теперь что-то, что сработало, уже не может исправить это?

Если бы вы использовали TDD и провели модульные тесты для приложения, сценарий не был бы таким. Это потому, что у вас есть тесты, сделанные для всего вашего приложения. После устранения ошибки вы просто снова запускаете модульные тесты, чтобы увидеть, не нарушит ли ваше «исправление» какие-либо другие вещи в вашем приложении.

Этот ответ больше нацелен на использование юнит-тестов. Ниже о самом TDD.

То, что TDD заставляет вас как отдельного человека, думать о том, что я собираюсь кодировать в следующем (объект, класс, функция и т. Д.). Кроме того, каковы границы моего кода, что если мне нужны операторы / else, что нужно проверять. Если вы один или в команде из 20 человек, это не имеет значения. Дело в TDD - это процесс мышления, а не других людей в вашем проекте.