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

голоса
50

Многие люди говорят о написании тестов для своего кода, прежде чем начать писать свой код. Эта практика, как правило, известен как Test Driven Development или TDD для краткости. Какие преимущества я получу от написания программного обеспечения таким образом? Как начать работу с этой практикой?

Задан 07/08/2008 в 03:27
источник пользователем
На других языках...                            


6 ответов

голоса
31

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

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

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

Ответил 07/08/2008 в 03:33
источник пользователем

голоса
3

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

Ответил 07/08/2008 в 03:30
источник пользователем

голоса
2

Выгоды

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

Начиная

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

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

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

Ответил 07/08/2008 в 03:34
источник пользователем

голоса
0

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

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

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

Ответил 02/02/2017 в 13:41
источник пользователем

голоса
0

Хороший стартер: Начало работы с TDD в Java с помощью Eclipse , Бретт Л. Schuchert

Есть множество скринкасто о TDD в Java и в C #. Он начинает с нуля и обучения основам TDD.

Ответил 03/06/2010 в 21:25
источник пользователем

голоса
0

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

Ответил 07/08/2008 в 03:32
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more