Почему я должен практиковать Test Driven Development и как мне начать?

Ответ 1

Есть много преимуществ:

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

Лучший способ начать - это просто начать. Существует большая книга Кент Бек о тестировании. Просто начните с нового кода, не волнуйтесь о старом коде... когда вы чувствуете, что вам нужно реорганизовать какой-то код, написать тест для существующей функции, а затем реорганизовать его и убедиться, что тесты остаются зелеными. Кроме того, прочитайте эту замечательную статью.

Ответ 2

Недавно была покрыта часть преимуществ , где и где начать... на небольшой системе предприятий, где не так много неизвестных, поэтому риски являются низкими. Если вы еще не знаете рамки тестирования (например, NUnit), начните с изучения этого. В противном случае начните с написания своего первого теста:)

Ответ 3

Преимущества

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

Начало работы

Просто сделай это. Напишите тестовый пример для того, что вы хотите сделать, а затем напишите код, который должен пройти тест. Если вы пройдете тест, отлично, вы можете перейти к написанию случаев, когда ваш код всегда будет терпеть неудачу (например, 2 + 2 не должен равняться 5).

Как только все ваши тесты пройдут, напишите свою фактическую бизнес-логику, чтобы делать все, что вы хотите.

Если вы начинаете с нуля, убедитесь, что вы нашли хороший набор тестов, который прост в использовании. Мне нравится PHP, поэтому PHPUnit или SimpleTest работают хорошо. Почти все популярные языки имеют набор для тестирования xUnit, позволяющий создавать и автоматизировать тестирование.

Ответ 4

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

Ответ 5

Хороший стартер: Начало работы с Tdd в Java с использованием Eclipse by Brett L. Schuchert

Является набором скринкастов о TDD на Java и в С#. Он начинается с нуля и основы обучения TDD.

Ответ 6

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

• Часть вашей команды не входит в цикл во время создания требований, спецификаций или историй пользователей.
• Большинство, если не все, ваших тестов являются ручными или у вас вообще нет тестов
• Даже если у вас есть автоматические тесты, они не обнаруживают реальных проблем.
• Автоматизированные тесты записываются и выполняются, когда слишком поздно для них, чтобы обеспечить реальное значение для проекта
• Всегда есть что-то более срочное, чем посвятить время тестированию
• Команды разделены между отделами тестирования, разработки и функционального анализа, и они часто не синхронизируются.
• Невозможность реорганизовать код из-за опасения, что что-то будет нарушено
• Слишком высокая стоимость обслуживания
• Время выхода на рынок слишком велико.
• Клиенты не чувствуют, что то, что было доставлено, - это то, что они просили
• Документация никогда не обновляется
• Вы боитесь разворачиваться на производство, потому что результат неизвестен.
• Вы часто не можете разворачиваться на производство, потому что тесты регрессии занимают слишком много времени для запуска
• Команда тратит слишком много времени, пытаясь понять, что делает какой-то метод или класс.

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