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

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

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

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

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

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

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

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

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

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

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

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

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

• сначала написав тест, вы указываете, что хотите, и доставляете только это, и ничего более - следовательно, экономя время на написание неиспользуемого кода
• без тестов, вы можете подумать, что результаты настолько очевидны, что вы ve done правильно - когда это не так. Тесты показывают, что вы сделали правильно. Это легко, и вы должны позволить себе немного поучиться и не расстраиваться, если поначалу кажется, что это медленнее.

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

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

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

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

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

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

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

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

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

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

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

Вы должны иметь тесты на месте, когда вы что-то фиксируете.

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

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

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