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

Question

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

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

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

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

Заранее спасибо!

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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

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

Answer 5

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

НО, в целом вы будете быстрее. Почему?

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

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

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

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

Answer 6

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

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

Answer 7

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

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

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

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

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

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

Answer 8

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

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

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

Answer 9

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

Answer 10

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