Оценка реализации проекта с TDD

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

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

5 4
tdd estimation

5 ответов:

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

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

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

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

2

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

4

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

1

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

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

(NB wrt Bug Fixing, я помню пару раз, когда либо я забыл реализовать пару случаев, либо были поздние дополнения к спецификации, дополнительная разработка была хитростью с тестами в место.)

0

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

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

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

0