Здравствуйте, blp, Вы писали:
L>>Внедряться полномочиями оно не может.
blp>Т.е. ответ на мой вопрос — в существующей команде по желанию, скажем, нового менеджера с TDD головного мозга внедрить TDD не получится.
Я не видел ни одного подобного внедрения, которое можно было бы назвать успешным.
L>>Нужен разработчик-маньяк, который немного пошатнет устои и поведет остальную команду за собой.
blp>Это очень красивый образ, но несколько неконкретный.
Ну так скажем. Укушенный. Который не может ни строчки написать, не написав для нее тест. Который на предложение прогнать прогу под отладчиком начнет брызгать слюной и бросаться на людей.
Большинство разработчиков имхо относятся к лагерю "могу тесты писать, но могу и не писать". Их не стоит принимать на вакантную позицию маньяка.
L>>Покрывать тестами код новый и/или изменяемый — можно и нужно. Вот именно это и должен показать этот самый маньяк, а спустя какое-то время оно обычно само получится
blp>Иэх. Это опять-таки очень неконкретно. Начиная откуда оно само получится?
Начиная с появления некоей критической массы тестов.
blp>А если рядом с маньяком работает бригада обезьян, педалящих тонны нетестируемого говнокода? Количество кода, который непротестирован при этом возрастает, также растет tech debt, связаный с тем, что добавить тесты — это надо рефакторить.
Здесь придется сначала разделять задачи и ответственность. Нельзя объять необъятное. Бригаду обезьян перевоспитать с наскока не получится, их надо медленно варить. Маньяка с командой лучше сначала изолировать на небольшом модуле, откуда тесты вскоре начнут расползаться по другим модулям. Однажды бригадир обезьян придет утром и обнаружит, что билд сломан. А сломан он потому, что юнит-тест, который незаметно для них стал частью билд процесса, перестал проходить. А проходить он перестал потому, что бригада обезьян закоммитила breaking change, не протестировав его никак. Они могут сначала попытаться саботировать, выбрасывая тесты из процесса сборки или просто закоммичивая их, но это только до первого устного выговора. Дальше придется учиться есть кактус.
L>>Как этого добиться? Ну, нужен маньяк. Еще нужна метрика.
blp>Метрика не работает. Код формально покрыт тестами, потому что понаписали тонну моков для всего на свете. по факту реальные сценарии тестируются процентов на 5, хотя код покрыт процентов на 80
Кстати, одна из причин, по которой я резко негативно отношусь в качестве использования этой метрики как показателя качества кода. Можно иметь 100% покрытие кода, но близкое к нулевому покрытие сценариев. Динамику изменения покрытия (растет/падает) использовать можно, особенно если можно быстро посмотреть, какой код вообще не покрыт. Но как абсолютную метрику — вряд ли.
>>Не работает схема, когда "тимлид сказал — пишем тесты", и все заверте... В принципе не работает.
blp>Это в прниципе понятно и очевидно. Мой вопрос был про реальные ситуации, когда произошел квантовый переход 
В частности про ту, что так красочно описана в блоге — сколько там напрмиер было людей в команде и какого размера был проект. А то сейчас выяснится, чот людей было 2 (я и Иа-Иа) и один из них был тот самый маньяк.
Размер команды не имеет такого большого значения. Конечно, в небольшой локализованной команде до 5-7 (кстати, размер команды из поста) разработчиков внедрять новые подходы намного легче, нежели в распределенной команде о 50 человеках. Нужно начинать снизу, с небольших команд.
Тут нужно еще понимать, какой будет выхлоп. Для одноразового кода вроде веб-фронтенда, который и так наполовину тестируется юзерами и переписывается каждые полгода с нуля согласно веяниям моды выхлопа может и не быть. Какие тут тесты — фигак-фигак и в продакшен.
Для кода, развитие и поддержка которого планируется на десятилетия вперед, выгода от внедрения юнит-тестирования во многих случаях будет состоять в разнице между "загнулись после первой версии" и "число установок растет двенадцатый год подряд". Описанный мной проект относился к этому классу.
В нем все сценарии поведения протестировать вручную было абсолютно, категорически невозможно. С автоматическим симулятором можно было покрыть большой домен сценариев, но он тоже был ограничен в возможностях. А с юнит-тестами мы могли обеспечивать симуляцию таких хитрых сценариев, которые вешним симулятором было просто не прогнать. Это если забыть на минуту о пользе от юнит-тестов во время собственно процесса разработки и о том, что наличие значительного количества юнит-тестов, покрывающих все ключевые сценарии работы юнитов и их взаимодействия обеспечили нам отличный набор для регрессивного тестирования. Что оказалось крайне удобным при работе над следующими версиями. Всем знакомо "добавить эту фичу сложно, так как поломаем все нахрен"? Вот-вот.
Загнать первую версию в продакшен авралом перед дедлайном можно. Растягивать аврал на годы вперед не выйдет.
