TDD с неясными требованиями

Question

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

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

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

Может ли кто-нибудь рассказать мне, как TDD можно применять в такой ситуации?

Заранее благодарен!

Answer 1

Я хочу видеть результат как можно скорее, чтобы понять, что мои идеи правильные или неправильные. Модульные тесты замедляют этот процесс.

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

Answer 2

TDD поможет вам выразить намерение вашего кода. Это означает, что, написав тест, вы должны сказать, чего вы ожидаете от своего кода. То, как ваши ожидания выполняются, является вторичным (это реализация). Задайте себе вопрос: «Что важнее, реализация или что такое предоставленная функциональность?» Если это реализация, вам не нужно писать тесты. Если это предоставленная функциональность, тогда сначала начнется тестирование тестов, которые помогут вам в этом.

Еще одна ценная вещь заключается в том, что по TDD вы не будете реализовывать функциональность, которая не понадобится. Вы пишете только код, который должен удовлетворить намерение. Это также называется YAGNI (вам это не понадобится).

Answer 3

Я считаю, что TDD работает особенно хорошо в подобной ситуации; Фактически, я бы сказал, что наличие неясных и/или изменяющихся требований на самом деле очень распространено.

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

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

Answer 4

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

У вас должны быть тесты на месте, когда вы что-то совершаете.

Answer 5

Это сообщение в блоге, которое я нашел могучим в объяснении использования TDD в очень итеративном масштабе процесса разработки: http://blog.extracheese.org/2009/11/how_i_started_tdd.html.

Answer 6

Использование TDD может заставить вас быстрее писать код - неспособность написать тест для конкретного сценария может означать, что в требованиях есть проблема.
Когда вы TDD, вы должны найти эти проблемные места быстрее, а не после написания 80% кода.

Есть несколько вещей, которые вы можете сделать, чтобы сделать ваши испытания более устойчивы к изменениям:

1. Вы должны попытаться повторно использовать код внутри ваших тестов в форме фабрики методов, который создает тест объекты вместе с методами проверки , который проверяет результат теста. Этот путь , если в вашем коде произошло некоторое изменение поведения , у вас есть меньше код для изменения в вашем тесте.

2. Используйте IoC контейнер вместо передачи аргументов к основным классам - снова, если сигнатура метода изменения, которые вам не нужно менять все тесты.

3. Сделайте свои юнит-тесты короткими и изолированными - каждый тест должен проверять только один аспект вашего кода и использовать структуру Mocking/Isolation, чтобы сделать тест независимым от внешних объектов.

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

Answer 7

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

НО, в общем, вы будете быстрее. Зачем?

• написав тест первой вы указываете, что вы хотите и доставки только что и больше ничего - значит сэкономить время написания неиспользуемого кода
• без тестов, можно подумать, что результаты настолько очевидно, что вы «Сделано правильно, когда это не так. Тесты показывают, что вы сделали правильно.
• вы получите более быструю обратную связь от автоматических тестов, чем делать ручное тестирование
• с ручным тестированием времени, необходимым для проверки все, как приложение растет быстро растет - значит, вы будете прекратить делать это
• с ручными тестами это легко совершать ошибки и «видеть» что-то проходящее, когда это не так, это особенно верно, если вы запускаете их снова и снова
• (хороший) модульные тесты дают вам второго клиента для вашего кода, который часто выделяется проблемы проектирования, которые вы могли бы пропустить иначе

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

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

Наконец, вы должны изучить некоторые методы BDD, чтобы улучшить то, что вы делаете с TDD. Начните с функции, которую вы хотите реализовать и спуститесь в код оттуда, вытащив истории, а затем сценарии. Сосредоточьтесь на реализации сценария решения по сценарию в тонких вертикальных срезах. Это поможет прояснить требования.

Answer 8

ИМХО, ваша главная проблема в том, когда вам нужно удалить какой-либо код. Это отходы, и это то, что должно быть рассмотрено первым.

Возможно, вы можете прототип или использовать «решения для шипов» для проверки требований и ваших идей, а затем применить TDD к реальному коду, как только требования будут стабильными.

Риск состоит в том, чтобы применить это и отправить прототип.

Также вы можете протестировать «солнечный путь» сначала и реализовать только оставшиеся, такие как обработка ошибок ... после того, как требования будут закреплены. Однако второй этап реализации будет менее мотивирующим.

Какой процесс разработки вы используете? Это звучит гибко, поскольку у вас есть итерации, но не в среде, полностью поддерживающей его.

Answer 9

Joshua Block прокомментировал что-то подобное в книге «Кодеры на работе». Его совет заключался в том, чтобы написать примеры того, как будет использоваться API (о длине страницы). Затем подумайте о примерах и API, и рефакторинг API. Затем напишите спецификацию и модульные тесты. Однако будьте готовы реорганизовать API и переписать спецификацию при реализации API.

Answer 10

TDD будет, для кого-то, замедлить начальную разработку. Итак, если начальная скорость разработки равна 10 в масштабе 1-10, при TDD вы можете обойти 8, если вы владеете навыками.

Это после этот момент становится интересным. По мере увеличения проектов эффективность разработки обычно снижается - часто до 3 в одном масштабе. С TDD очень возможно оставаться в диапазоне 7-8.

Посмотрите «технический долг» для хорошего чтения. Насколько мне известно, любой код без модульных тестов - это фактически технический долг.

Answer 11

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

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

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