Comments 14
не идеально соблюден SOLID, YAGNI, DRY и вот это все, но есть хорошее покрытие тестами
Спорное утверждение. Несоблюдение SOLID может привести к усложнению юнит тестов. Начинают писать юнит тесты, которые должны проникнуть в такие дебри, что бы добиться хотя бы относительного покрытия, что мама не горюй, если боец до ночи не вернется до дому. Или юнит тесты даются с таким трудом, что получаются интеграционные тесты. Потом поддержка тестов приводит к тому, что либо их удаляют, потому как не ясно, что в ём сломалось, либо боятся код трогать и пишут рядом новый метод и новый юнит тест.
Организовывать код в проектах надо так, чтобы любой разработчик, даже только что пришедший в команду, мог за 2 команды в консоли установить зависимости для работы и локально запустить тесты. Тесты запущенные локально должны соответствовать тестам в пайплайне.
Только, как мне кажется, TDD маленько не про это, так же как и не мешает оно ООП
Я не хочу сказать, что соблюдать хорошие практики не надо (я за них обеими руками), лишь только, что мне легче работать с проектами, у которых есть хорошее покрытие тестами и эти тесты можно быстро прогнать.
Просто в реальной корпоративной разработке я повидал очень много разного и хорошей архитектуры, и SOLID и скрипты на 1.5к строк и оверинженерной архитектуры, где у каждого класса был свой абстрактный родитель, который даже мог быть пустым, но на всякий случай его создавали. Не всегда работаешь в идеальных условиях ¯\_(ツ)_/¯.
Я согласен, что тесты тестам рознь и бывают такие случаи, что лучше бы их не было, потому что становятся или очень хрупкими, или так обмазанные моками, что уже непонятно выполняется ли там хоть что-то реальное. Поэтому я и оговорился про хорошее покрытие. Эмпирически с чем работал, если > 70%, то уже все не так плохо в проекте. Такой код можно более менее спокойно рефакторить или пилить новые фичи.
Про хорошие практики тестов по крайней мере на Python еще точно поговорим в будущем.
Юнит тесты являются антипаттерном. Как, впрочем, и SOLID.
Хорошая мысля. Я согласен с тобой TDD - это реальн про скорость и качество, а не просто про порядок написания теста и кода. За 15 минут и возможность легко запустить тесты это прям мечта, экономит много времени и нервов
Странно, что вы не стащили у меня и вторую картинку из этой статьи с исправленным циклом TDD:
Можно уточнить?
Вы прочитали книгу Бека "Экстремальное программирование. Разработка через тестирование", и всё, что из неё вынесли — вот этот "секрет"?
Главный секрет TDD не в том, что тесты пишутся первыми, а в том, что цикл обратной связи должен занимать не больше 15 минут.
Я правильно понял?
Уточнить нельзя)
И поняли неправильно)
Стандартная история про методологию разработки обговорена со всех сторон по 100 раз, захотелось высказать что-то, что мне лично показалось не очевидным, т. к. не вижу 100500 статей об этом. Может быть именно к TDD притянуто за уши, но впервые с этой идей столкнулся именно там. И мне понравилось, как другие советы и правила методологии эту идею дополняют.
И жаль, что уточнить нельзя, а то я бы это сделал…
…Подтвердив, что TDD —конечно же! — про обратную связь. Но не только про неё.
Весь "agile" про обратную связь. Всем хочется как можно быстрее понять, правильные решение было принято или нет.
Но вот только жизнь устроена так, что одного желания обычно недостаточно — нужно ещё придумать, как это желание воплотить в жизнь. И TDD — про комплекс мер по достижению этого (и, на самом деле, не только этого — так как и сама проблема сложная, многокритериальная, да ещё и динамическая).
В итоге как-то так получается, что, с одной стороны, вы подчёркиваете важную деталь, но при этом упускаете целое. И в результате статья больше не помогает, а, скорее, мешает понять (целостный) смысл TDD.
Но при этом есть гипотеза, что стоит лишь чуть-чуть сместить акцент — говорить не про "Главный секрет TDD", а про "одну из (возможно, неочевидных …почему-то) целей, которые (действительно!) позволяет (не просто хочет, а именно позволяет — как раз благодаря комплексности) достичь TDD (…правда не сразу)", — как ценность статьи возрастёт немедленно и очень сильно.
И то, что понял не правильно — хотя очень старался понять правильно, — возможно, подтверждает эту гипотезу?
(Изложил многословно и сложновато, конечно — требуется рефакторинг. Но сначала надо заставит тест позеленеть.)
TDD и цикл обратной связи