Pull to refresh

TDD — это как сноубординг

Reading time 3 min
Views 12K
Original author: Jean-Paul S. Boodhoo

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

«Я не использую эту методологию (TDD) из-за того, что главный для меня вопрос остается без ответа. Я знаю, что использование TDD уменьшает количество багов, но что насчет времени, необходимого при работе по этой методологии?
Я хотел бы знать как изменяется время на разработку корпоративного приложения с использованием TDD — уменьшается, увеличивается или остается неизменным.
Надеюсь, вы сможете ответить, так как TDD и BDD меня очень интересуют.»


Первая и самая важная вещь, на которую я хотел бы обратить внимание, — ошибочное представление о TDD как об инструменте для уменьшения количества багов. Хотя это и является одним из «побочных эффектов» TDD, это не основной мотив для его использования. Главный довод в пользу TDD — последовательная разработка дизайна каждого компонента вашей системы посредством написания теста для него.

Что касается следующего вопроса:

«Я хотел бы знать как изменяется время на разработку корпоративного приложения с использованием TDD — уменьшается, увеличивается или остается неизменным.»

Когда вы впервые решаетесь забраться на гору и рискнуть прокатиться на сноуборде, вы забираетесь туда с мечтой в голове о том как будете рассекать несколько минут и выделывать трюки круче, чем в SSX Tricky. Но после пары падений вы чувствуете увесистый пинок реальности и осознаете, что, похоже, это займет немного больше времени, прежде чем вы научитесь хотя бы просто съезжать с горы без всякого блеска и очарования. Если вы благоразумны, то потратите время на занятия с квалифицированным инструктором, который за день обучит вас основам и поставит технику. На базе занятий с интруктором вы сможете расти как сноубордист следующие пару месяцев, и, скорее всего, не нахватаетесь вредных привычек, которыми могли бы обзавестись, попытайтесь вы научиться самостоятельно.

Как в сноубординге (да и в любом другом новом деле, которое вы решили освоить), в начале нужно потратить время на обучение. Большинство людей, решивших окунуться в TDD, осознают, что в их знаниях много пробелов, которые могут создать проблемы в этом новом мире. Даже если со знаниями у вас все в порядке, вы должны осознавать, что в любом случае первое время вы будете тренировать свой мозг решать программные проблемы непривычным способом. На самом деле, это одно из самых больших препятствий при переходе на TDD — выработка нового стиля программирования, который заставляет вас думать о маленьких шагах и разрабатывать API, как будто он уже написан. Хороший способ начать практиковать TDD — использовать state-based тестирование (от перев. — подход, при котором проверяется состояние объекта после прохождения теста). Как только вы набьете руку на state-based тестировании, вы сможете сочетать его с interaction-based тестированием (от перев. — подход, при котором тестируется взаимодействие объектов, поведение методов, последовательность их вызовов и т.д.).

Начав использовать TDD, вы можете обнаружить, что работаете медленнее, чем обычно, — это в основном из-за того, что вы будете работать вне «зоны комфорта», чувствуя себя неестественно. После того как вы ощутите, что написание тестов стало естественной частью рабочего процесса, что вам больше не нужно думать об использовании TDD при работе над проектом, так как TDD влилось в вашу работу, вы поймаете ваш «АГА!» момент с TDD.

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

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

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

Для тех из вас, кто всерьез рассматривает использование TDD, но еще не начал, — возможно, сейчас хороший сезон, чтобы попробовать взобраться на холм!

Tags:
Hubs:
+31
Comments 58
Comments Comments 58

Articles