Я ищу возможное исследование между разницей времени обычного кодирования и кодированием + модульные тесты (пока еще не строгий TDD). Я знаю, что все "экономит ваше время в долгосрочной перспективе", но с точки зрения планирования проекта для команды, которая никогда не делала этого раньше, мне нужно иметь возможность приблизиться к оценке того, сколько дополнительного времени для распределения.
Существует ли такое исследование? Может ли кто-нибудь прокомментировать опыт?
Я знаю, что пока вас не интересует полный TDD, но я думаю, что лучшие маркеры производительности и планирования будут найдены в тематических исследованиях, связанных с тестированием, например, проводимых как Microsoft, так и IBM.
Тематические исследования проводились с тремя разработчиков в Microsoft и один в IBM, которые приняли TDD. результаты тематических исследований показывают что плотность дефектов перед выпуском четыре продукта уменьшились между 40% и 90% по сравнению с аналогичными проекты, которые не использовали TDD практика. Субъективно команды увеличилось на 15-35% начальное время разработки после принимая TDD. Источник
Это часть предисловия к полному сравнению нормального развития с разработкой с использованием модульного тестирования в качестве основного принципа. Предварительное дополнение к планированию развития, которое мы используем, составляет 20%, что включает в себя как модульные, так и интеграционные тесты. Во всех тестах честности жизненно важно для любого успешного программного обеспечения, модульное тестирование просто удаляет некоторые жесткие ярды и ручное усилие. Неоценима возможность запуска нескольких сотен единиц и интеграционных тестов после завершения немного функциональности и возможности тестирования системы в течение нескольких секунд.
Есть несколько разных "магических" чисел, которые люди добавляют к своим оценкам, чтобы добавить дополнительное время для написания модульных тестов, но на самом деле это просто сводится к простому компромиссу. По сути, вы балансируете увеличение времени разработки против увеличения времени исправления ошибок/проверки ошибок, также принимая во внимание сходство времени простоя и критичности системы (если это первичный доход или несущественная система).
Если вы заинтересованы в том, чтобы немного читать здесь, это полное исследование Microsoft. Его довольно короткий, но дает некоторые интересные выводы. И если вы действительно заинтересованы здесь - это единое тестирование слайд-шоу, в котором излагаются концепции и преимущества в разумных деталях (ранее это была ссылка на исходное содержимое эту презентацию, но, к сожалению, контент теперь ушел).
Во всех ситуациях, во всех командах это должно быть правильно:
TimeOf(Coding+Testing) < TimeOf(CodingWithoutTesting)
Не нужно больше времени. Или это станет бесполезным.
Я не могу комментировать исследования для этой темы.
Из опыта я бы сказал, что ваш магический диапазон колеблется от 30 до 40%, так как ваша команда новичок в этом. Ваша команда должна будет научиться создавать издевательства и подделки, а также привыкнуть к написанию тестов, а также к настройке инфраструктуры, множеству авансовых расходов, пока ваша команда не начнет ускоряться. Если ваш основной язык - С++, тогда требуется больше усилий для написания моков и подделок, чем с С# (из моего опыта). Если ваш проект представляет собой совершенно новый код, то это потребует меньше усилий, чем работа с существующим кодом. Если вы можете быстро довести свою команду до скорости при тестировании, то TDD окажется меньше усилий, чем написание тестов после этого. Имея достаточный опыт, время тестов, вероятно, составляет около 20%, еще одно волшебное число. Простите, что у меня нет точных цифр, у меня нет точных показателей из моего опыта.
Как кто-то, кто в настоящее время работает над своим первым проектом с использованием модульных тестов (а не с полноразмерным TDD, но рядом), я бы сказал, что вы должны удвоить время, которое обычно требуется для вашей команды, чтобы выполнить свою первоначальную реализацию.
Книга Роя Ошерове, Искусство модульного тестирования, имеет неофициальное исследование, которое показывает это, но также показывает, что когда включаются циклы QA, общее время выпуска было немного ниже при использовании модульных тестов, и в коде, разработанном с модульными тестами, было гораздо меньше дефектов.
Я бы сделал следующие предложения:
Попросите ваших программистов прочитать все, что они могут получить на модульных тестах и TDD, особенно все, что они могут найти, о том, как разработать код, дружественный к тестированию (использование инъекции зависимостей, интерфейсов и т.д.). Книга Ошерове станет отличным началом.
Начните оценивать рамки модульного тестирования (NUnit, xUnit и т.д.) и Mocking frameworks (Rhino Mocks, Moq и т.д.) и выберите их для стандартизации. Наиболее популярными являются, вероятно, NUnit и Rhino Mocks, но я выбрал xUnit и Moq.
Не позволяйте своим программистам сдаваться. Трудно изменить свое мышление и преодолеть естественное сопротивление изменениям, но им нужно проработать это. Первоначально это может показаться, что модульные тесты просто мешают, но в первый раз они реорганизуют разделы кода "на лету" и используют модульные тесты, чтобы знать, что они ничего не сломают, а не надеются, что они не станут откровением.
Наконец, если это возможно, не начинайте модульные испытания большого проекта высокого давления с ограниченным сроком; это, вероятно, приведет к тому, что они не преодолеют свои первоначальные трудности и откалывают единичные тесты в пользу только того, чтобы сделать код.
Надеюсь, это поможет!
Мне нужно судить о том, сколько дополнительного времени нужно выделить.
Это глупо. Нет дополнительного времени.
Вот что вы делаете. Возьмите свой существующий бюджет тестирования. 40% усилий по развитию в конце проекта.
Распространение большей части этих усилий по тестированию в течение всего срока службы проекта в качестве модульного тестирования. Назовите это 30% от общего количества усилий, распределенных повсюду.
Оставь часть тестирования в конце для тестирования "интеграции" и "производительности". Назовите это 10% от общего количества усилий, выделенных только в конце и только для интеграции и тестирования производительности. Или Тестирование приёма пользователей или что осталось, что вы не unit test.
Нет "дополнительных". В любом случае вам нужно пройти тестирование. Вы можете либо сделать это, как первоклассное программное обеспечение, во время проекта, либо вы можете скреститься в конце проекта, выполняя плохую работу.
"Стоимость" TDD - в лучшем случае - субъективное впечатление. Внимательно прочитайте подробное резюме. "Субъективно, команды получили 15-35% -ное увеличение начального времени разработки после принятия TDD". [Акцент добавлен.]
На самом деле для TDD существует нулевая стоимость. TDD просто экономит время.
Это намного дешевле делать TDD, чем создавать другие программы.
Почему?
Вы должны все равно протестировать. Поскольку вы должны протестировать, вы можете также планировать тестирование, управляя всеми своими разработками вокруг тестирования.
Когда у вас сломанный тестовый пример, у вас есть целенаправленный набор задач. Когда вы прерываетесь телефонными звонками, встречами, демонстрациями продуктов, операционными вызовами для поддержки предыдущих выпусков, легко отвлекаться. Когда у вас заканчиваются тесты, вы сразу же получаете фокус.
Вы должны все равно протестировать. Это либо Code, либо Test, либо Test, а затем Code. Вы не можете избежать затрат на тестирование. Поскольку вы не можете убежать, сделайте это сначала.
Идея, что TDD имеет "дополнительные" или "дополнительные" затраты, безумна. Даже хорошо документированное исследование, такое как http://www.springerlink.com/content/q91566748q234325/, не может фактически сравнивать один и тот же проект двумя способами. Идея "дополнительного времени разработки" фактически не может быть измерена. Вот почему это "субъективное впечатление". И они просто ошибаются.
Когда вы спрашиваете программистов - кто новичок в TDD - если TDD замедлил их, они лгут об этом.
Да. Они лгут.
Один. Вы заставили их измениться. Изменения плохие. Всем это известно. Они не могут сказать, что это было проще, потому что это было "другое".
Два. Это ставит под вопрос управление. Мы не можем сказать плохо о наших менеджерах, что плохо. Всем это известно. Они не могут сказать, что это было проще, потому что предыдущие вещи, которые требовали наши менеджеры, теперь явно ошибочны.
Три. Большинство программистов (и менеджеров) считают, что существует различие между "реальным" кодом и "тестовым" кодом. TDD занимает больше времени, чтобы перейти к "реальному" коду, потому что вы тратите свое время перед выполнением "тестового" кода.
Этот "реальный" код по сравнению с "тестовым" кодом является ложным различием. Любой, кто говорит это, не понимает, насколько важно тестирование. Поскольку тестирование является центральным для демонстрации того, что приложение работает, тестовый код должен быть первоклассным. Сделать это различие неверно. Код проверки - действительный код.
Время, затрачиваемое на выполнение тестового кода, - эффективно - время, отведенное от дизайна реального кода. Вместо того, чтобы создавать "бумажные" проекты, вы создаете рабочий, живой дизайн в форме тестовых случаев.
TDD экономит время.
Люди, которые говорят иначе, сопротивляются изменениям и/или пытаются защитить управление от неправильного представления и/или сделать ложное различие между реальным кодом и тестовым кодом. Все, что просто неправильно.
Я бы не стал полагаться на исследование, чтобы сказать вам, что вы можете просто проработать его самостоятельно.
Обычно разработчик разбивает основные функции на более мелкие задачи, а затем оценивает время, которое будет выполняться каждой задачей. В рамках этой задачи они также могут оценивать, какие задачи (или части функциональности) являются проверяемыми единицами, а затем в этот момент они также могут записывать задачи и оценки для записи этих конкретных тестов. Экситаты для модульных тестов должны иметь одинаковую погрешность, применяемую в качестве кода, который они тестируют, - чем сложнее проверенный код, тем сложнее тест (и, следовательно, более вероятно, что оценка для записи теста будет идти по графику).
Конечно, ни одна из них не является совершенной наукой, если бы она не нуждалась в менеджерах проектов:) Если вы просто ищете оценки высокого уровня, то любая цифра, которую вы даете для части тестирования модуля, будет как неточно, как цифра, которую вы даете для фактического кода. У вас не будет никакой уверенности или точности, пока вы не разделите ее на задачи, а затем примените к нему соответствующие шкалы (например, вам необходимо учитывать истинную скорость кодирования разработчика, которая может составлять только 60% - 70%).