Оценка реализации проекта с помощью TDD - PullRequest
Новая
       21

Оценка реализации проекта с помощью TDD

4 голосов
/ 28 апреля 2010

Существуют ли какие-либо рекомендации при цитировании оценок для проектов / задач, связанных с TDD?

Например, если сравнивать с обычной разработкой задачи, занимающей 1 день, сколько еще должно занять задание, управляемое TDD? На 50% больше времени или на 70% больше времени? Имеется ли статистика, если разработчик хорошо разбирается в языке и тестовой среде?

Ответы [ 5 ]

4 голосов
/ 29 апреля 2010

По моему опыту, написание тестов занимает столько же времени, а иногда и даже больше, чем разработка (т. Е. Добавляет от 100% до 150% больше времени), но значительно сокращает время, затрачиваемое на исправление ошибок. Вот некоторые Исследования по разработке через тестирование . Также взгляните на эту бумагу .

2 голосов
/ 29 апреля 2010

Сначала разница велика, уменьшается с опытом, но, вероятно, всегда является фактором

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

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

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

1 голос
/ 29 апреля 2010

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

0 голосов
/ 04 июня 2012

Если вы хотите получить математический ответ, мои выводы были потрачены на тестирование: производство составляет 2: 1 (консервативный - большая часть времени, потраченного на тестирование, - ДУМАЮ).Однако вы не можете применить 3-кратный коэффициент к вашим текущим (не TDD) оценкам, потому что TDD помогает вам стабильно прогрессировать ... вы не тратите время

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

Сверхумоей головы, я бы пошел на 2X на ваши существующие оценки.

0 голосов
/ 01 мая 2010

Другая выгода при создании кода с TDD заключается в том, что написанные тесты становятся набором регрессии. Затем тесты делают эти действия намного более безопасными:

  • Рефакторинг по факту.
  • Дальнейшая разработка того же кода.
  • Исправление ошибок.

(Примечание: исправление ошибок, я помню пару раз, когда либо я забыл реализовать пару случаев, либо были поздние добавления к спецификации, дополнительная разработка была пустяком с тестами на месте.) *

...