Попробуй посчитать вероятность возникновения ошибки по другому: у тебя в программном модуле есть N методом и в каждом из них ты можешь сделать ошибку с вероятностью, пропорциональной количеству строчек кода, реализующих бизнес-логику. Вероятность допустить ошибку является композицией от вероятностей сделать ошибку в этих N методах. В случае TDD ты пишешь N тестов, чтобы покрыть функциональность методов (при правильном применении ТДД количество тестов будет соответствовать количеству методов, при неправильном — количество тестов будет больше, чем количество методов). Соответственно, вероятность возникновения ошибок в тестах считается так же. Так-как функциональность методов пишется после создания тестов, то вероятность возникновения первичной ошибки в тестах считается первичной, то при возникновении ошибки в тесте реализация уже будет неправильной. По этому вероятность ошибки реализации программы в целом будет считаться как сумма вероятностей от ошибки в тесте и одновременной ошибки и в тесте и в реализации.
Соответственно, при увеличении строк кода в тесте и увеличении N вероятность ошибки увеличивается. Откуда были получены эти «в разы» мне, лично, непонятно.
Функционал проверяется тестировщиком, который вначале с продактом пишет/уточняет тест-план, а потом составляет список регресс-тестов.
Время на прохождение тестов и правку багов обычно соотносится как 2 к 1 по отношению к времени разработки. Увеличение до 7 к 3 является поводом для тотального код-ревью.
Сильно зависит от скорости мутации требований. Обычно на обсуждение функционала выделяется по 1-1,5 часа два раза в неделю при эффективном рабочем времени в 30 рабочих часов в неделю.
«И другой вопрос — тратить время хотя бы на unit-tests или нет.»
Коль, моя позиция проста: тратить время на юнит тесты необходимо, но не везде. Юнит тестами надо покрывать внешние интерфейсы атомарных модулей. Критерий атомарности модуля —
а. код, который может по требованиям написать средний программист компании с 0 за неделю
б. критически важный для системы сегмент, вынесенный по этим причинам в отдельный компонент
Да, именно так. Хороший программист вполне способен сам уточнить требования у продакт-менеджера, для этого продакт и нужен, чтобы быть медиатором между бизнес задачами и задачами разрабоки.
Прочитайте пожалуйста: habrahabr.ru/blogs/tdd/112685/#comment_3611572
ТДД далеко не всегда экономически оправдано. Вы рассуждаете, как программист, я рассуждаю, как человек, который платит программистам зарплату из своего кармана.
Соответственно, при увеличении строк кода в тесте и увеличении N вероятность ошибки увеличивается. Откуда были получены эти «в разы» мне, лично, непонятно.
Время на прохождение тестов и правку багов обычно соотносится как 2 к 1 по отношению к времени разработки. Увеличение до 7 к 3 является поводом для тотального код-ревью.
Коль, моя позиция проста: тратить время на юнит тесты необходимо, но не везде. Юнит тестами надо покрывать внешние интерфейсы атомарных модулей. Критерий атомарности модуля —
а. код, который может по требованиям написать средний программист компании с 0 за неделю
б. критически важный для системы сегмент, вынесенный по этим причинам в отдельный компонент
ТДД далеко не всегда экономически оправдано. Вы рассуждаете, как программист, я рассуждаю, как человек, который платит программистам зарплату из своего кармана.