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

Какой процент времени экономится и стоит на TDD.

Я предполагаю, что этот процент изменений стоимости и вознаграждения в течение жизненного цикла проекта.

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

Я слышал, что где-то 30-50% вашего времени пишут юнит-тесты. Однако это не учитывает время, сэкономленное на написании этих тестов.

Каков опыт каждого с этим?

Wes

РЕДАКТИРОВАТЬ Сколько времени сэкономлено, а также время? В исправлении ошибок и рефакторильности?

Я слышал, что где-то 30-50% вашего времени пишут юнит-тесты. Однако это не учитывает сэкономленное время

По моему опыту, это более 50%.

После того как вы написали тест, решение имеет тенденцию быть очень простым. Поэтому я не думаю, что странно тратить 70% - 75% вашего времени на написание тестов, но вы тратите гораздо меньше времени на написание «производственного кода» (тестируемого кода) и практически не тратите время на отладчик. ,

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

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

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

От 30 до 50% времени, которое вы указываете на необходимость написания тестов, также в значительной степени компенсируется преимуществами лучшего (тестируемого) дизайна программного обеспечения.

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

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

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

TDD часто измеряется по качеству кода, а не по затратам времени и средств. Однако при лучшем качестве кода разработчики и все, кто с ними работает, могут работать лучше (меньше затрачиваемого времени, меньше затрат, больше счастья и т. Д.). http://davidlongstreet.wordpress.com/2009/04/29/new-software-metric-wtfs-per-minute/

Написание тестов отлично подходит для автоматизации проверки функциональных и нефункциональных требований. Одно видео, которое убедило меня принять TDD (на самом деле BDD, TDD высокого уровня): http://video.google.com/videoplay?docid=8135690990081075324#

• Написание функциональных тестов может помочь выявить ошибки / проблемы на ранних этапах разработки . Предположим, у вас есть большая база кода. Для модульных тестов / спецификаций вам нужно только увидеть «Все тесты пройдены» / «2 теста не пройдены, см. Строку xyz». Вам нужна только команда разработчиков для разработки и тестирования. Без модульных тестов / спецификаций вам придется вручную сравнивать напечатанные операторы с ожидаемыми и вручную отслеживать, какие методы / классы содержат ошибки. Вам, вероятно, понадобятся две отдельные команды (разработчики и тестировщики), чтобы сделать это.

• Письменные тесты помогают разработчикам объяснить прогресс и возникшие проблемы.

• TDD помогает обеспечить удобство сопровождения, адаптивность и гибкость кода. Это побуждает разработчиков писать небольшие тестируемые блоки и объединять их в большие тестируемые блоки. Обратный путь (часть практики рефакторинга) также работает, при условии, что мы написали надежные тесты. В результате мы можем получить красиво написанный модульный код.

С TDD мы рады знать, когда:

• клиент запрашивает изменения требований (удовлетворяющих требованиям)
• обнаружены лучшие способы написания кода
• у товарищей по команде есть предложения по улучшению кода
• мы должны объяснить / передать наш код другим людям

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

В нашем случае я бы оценил, что это близко к 40%. Тем не менее, я не думаю, что мы прошли этап, когда это было больше, чем это. У нас есть генератор кода, который выкладывает как скелет кода, который дорабатывается разработчиками, так и набор тестов, который также дорабатывается. Большая часть наших усилий по тестированию фактически направлена ​​на отслеживание (или создание) соответствующих тестовых данных, чтобы обеспечить полное покрытие.

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

краткосрочные меры будут окупаемостью автоматизации испытаний

Например: на прошлой неделе я сделал более 1000 изменений кода из-за изменения внутренней архитектуры, запустил автоматизированный набор тестов и пошел спать.

тесты заняли 28 минут; они все прошли. выполнение тех же 40+ приемочных испытаний вручную заняло бы около 6 часов.

другой пример: в предыдущей итерации я обдумал один из сценариев тестирования с тонкой ошибкой, которую ручное тестирование, вероятно, не обнаружило бы (автоматические тесты выполняют проверки целостности БД, которые ручные тестеры почти никогда не делают). Я должен был выполнить этот тестовый сценарий примерно 50 раз, прежде чем мне удалось выяснить и исправить это. Выполнение операций тестового сценария вручную займет около 50 минут. Таким образом, за один день сэкономлено 41,6 человеко-часов.

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

но для меня рентабельность автоматизированных испытаний почти бесконечна

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

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

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