Так же часты, как и в любом другом коде, да и вообще в точности такие же, никакой разницы по сложности обнаружения и отладки. Ну, это точно такой же обычный код, с чего бы вообще там багам отличаться?
Тем, что тесты максимально просты, с низкой цикломатикой и вариативностью, не вложенные, не используют (за исключением) массу новых типов. Не должны работать на граничных значениях элементов и как правило читабельнее кода.
Сложный и работающий проект без изменений и тестов просто тупо работает и все, потому что написан нцать лет назад и чего бы ему не работать?
Откуда у вас такая выборка? Не припомню сложных проектов которые работают и в них не фитуют. Кроме тех которые бояться трогать.
Я понимаю что простым и одноразовым проектам тесты не нужны.
Изменяемым с горизонтами год и более — нужны
Про болванов и обиженных речь не идет. Ревьюверы ошибаются, имеют свое мнение и пропускают мимо глаз. Ревьюверы не видят регрессивных изменений. Ревьюверы не роботы. Tests are.
— Их надо писать — но они дают выигрыш на горизонте.
— Баги в тестах прозрачны, легко ревьювятся и редки
— Поддерживать тесты надо при изменении API в уже написанном коде. В этот момент тесты подсвечивают изменения произошедшие в контрактах. Это то же время, что вы бы провели в дебаге.
Сложный и работающий долгое время проект без изменяй и тестов — обречен на переписывание. В то же время есть вероятность что изменения в него не вносятся именно по этой причине.
Не панацея, но более чем в половине случаев они необходимы. Безусловно речь идет не про стартапы/выставки/сайт визитки. И речь не идет от 100% покрытие.
А полагаться на ревьювера как на истину это очень странно.
К сожалению не владею Rust, но в C#-Java-Kotlin следование принципам Solid, а особенно (S)ingleResponsobility отсекает много ошибок на уровне синтаксиса.
Например, при рефакторинге наткнулся на очень запутанный класс RequestInfo. Он являлся одновременно и сущностью ORM, и DTO для HttpClient и DTO между слоями.
Разделил этот класс на 4 (!!!) разных класса, каждый из которых занимался чем то конкретным. И тут… код прекратил компилироваться, поскольку оказалось что в оригинале, межслойный Dto шел в HttpClient минуя БД. Я пошел к оригинальным авторам и они сказали «О, так и в правду не должно было быть». Мне понравилось ;)
Зачем я должен это гарантировать? Если я пробрасываю зависимость через свойство, то я тем самым говорю «Есть поведение и вы можете менять его в любой момент». Яркий пример — зазоры для тестирования. Вы же не хотите передавать все параметры включая NowTimeLocator, ThreadSleeper, итд каждый раз.
Признаюсь. Я писал IDE редактор, разделив его на два слоя — ядро (правильное решение) и всё остальное (ой).
Под всем остальным понималась смесь модели, вьюмодели ксамл кс вьюх (дело было в впф), логики и чего то ещё( похоже мой мозг стирает такие негативные воспоминания). Неймспейсы и папки проекта были рандомными, а в одном файле могло быть до 10ти классов. И не обязательно однотипных.
Вообще ничего не было обязательным. Сальвадору дали дали студию. Зря ;)
Оно работало и его не трогали, пока, спустя два года, один проект созданный на этом монстре не стал открываться по 40 минут, а через 40 минут радостно выдавал OutOfMemory.
Последние 7 месяцев были потрачены на разделение этого барахла на 4 слоя, с юнит тестами SOLID, и MVVM. Это лучший опыт в моей жизни, хоть и на мёртвой технологии. Теперь дзен…
П.С. Я не думал что когда нибудь это всё расскажу, но раз такая пьянка… С души отлегло.
А потому давайте использовать в качестве приоритета дату, которая изредка будет иметь свой реальный в смысл, но в общем — это просто 64х битный приоритет. Окама, фигли!
Также есть ощущение что мы говорим про одно и то же, просто понимание «простого» и «сложного» проекта у нас численно различаются.
Тем, что тесты максимально просты, с низкой цикломатикой и вариативностью, не вложенные, не используют (за исключением) массу новых типов. Не должны работать на граничных значениях элементов и как правило читабельнее кода.
Откуда у вас такая выборка? Не припомню сложных проектов которые работают и в них не фитуют. Кроме тех которые бояться трогать.
Я понимаю что простым и одноразовым проектам тесты не нужны.
Изменяемым с горизонтами год и более — нужны
А вот Lion да… было ощущение что после загрузки будет черный экран и надпись «42» с последующим взрывом
— Их надо писать — но они дают выигрыш на горизонте.
— Баги в тестах прозрачны, легко ревьювятся и редки
— Поддерживать тесты надо при изменении API в уже написанном коде. В этот момент тесты подсвечивают изменения произошедшие в контрактах. Это то же время, что вы бы провели в дебаге.
Сложный и работающий долгое время проект без изменяй и тестов — обречен на переписывание. В то же время есть вероятность что изменения в него не вносятся именно по этой причине.
А полагаться на ревьювера как на истину это очень странно.
Например, при рефакторинге наткнулся на очень запутанный класс RequestInfo. Он являлся одновременно и сущностью ORM, и DTO для HttpClient и DTO между слоями.
Разделил этот класс на 4 (!!!) разных класса, каждый из которых занимался чем то конкретным. И тут… код прекратил компилироваться, поскольку оказалось что в оригинале, межслойный Dto шел в HttpClient минуя БД. Я пошел к оригинальным авторам и они сказали «О, так и в правду не должно было быть». Мне понравилось ;)
Уменьшение сложности в сильносвязанном коде с магическим оттенком — илюзорно. Только по количеству строчек кода.
Выводы:
Под всем остальным понималась смесь модели, вьюмодели ксамл кс вьюх (дело было в впф), логики и чего то ещё( похоже мой мозг стирает такие негативные воспоминания). Неймспейсы и папки проекта были рандомными, а в одном файле могло быть до 10ти классов. И не обязательно однотипных.
Вообще ничего не было обязательным. Сальвадору дали дали студию. Зря ;)
Оно работало и его не трогали, пока, спустя два года, один проект созданный на этом монстре не стал открываться по 40 минут, а через 40 минут радостно выдавал OutOfMemory.
Последние 7 месяцев были потрачены на разделение этого барахла на 4 слоя, с юнит тестами SOLID, и MVVM. Это лучший опыт в моей жизни, хоть и на мёртвой технологии. Теперь дзен…
П.С. Я не думал что когда нибудь это всё расскажу, но раз такая пьянка… С души отлегло.