Определение юнит тестов у автора достаточно широкое: тесты которые можно написать на фреймворке у которого есть unit в названии.
Я предпочитаю разделять юнит тесты и прочие тесты (интеграционные, компонентные, изоляционные). Границы всё равно несколько размыты и для каждого проекта нужно решать самому.
Юнит тесты, это что-то простое, без моков (но с заглушками), без соединений с базой, привязаны к конкретным классам и функциям, в том числе и внутренним, обычно чистым. Фокус тут на куске кода и его покрытие. Их жизненный цикл связан с их юнитом. Поменялся юнит, поменялись тесты, не поменялся, тесты должны продолжать проходить.
В месте где я сейчас работаю, всё остальное зовётся изоляционные тесты. И e2e с моками и тестирование отдельных модулей с моками. Сложность и хрупкость тут частые гости.
Эти две группы тестов требуют разного подхода, чистые юниты очень дешёвые в написании и поддержке и позволят быстро отлавливать часть проблем. Пирамида тестирования она как раз об этом.
Опыт ЕДИНОГО ЦУПИС показал, что контроль цепочки поставок в Java можно встроить в существующий процесс разработки без слома CI/CD и без остановки релизов.
И что можно класть болт на безопасность при работе в финтехе.
Тут да, но даже простая задержка доступности во внутреннем хранилище может помочь. Ну и если все зависимости идут через своё хранилище, можно быстро отключить зависимость.
За 25 лет можно и связи построить. Да и рекрутёры будут за вами бегать, а не вы за ними. Состаявшимся специалистам легче, чем начинающим.Да и рынок сейчас не в самой лучшей форме.
Понимание, какие тесты нужно гонять, а какие - нет это ключ к успешном проекту. Если нет такой цели, то нужно понимать, что проект проживет по инерции какое-то время, а потом загнется. А с подходом давайте гонять все - это тупик.
Мне кажется мы о разном говорим. Поддержание тестов в актуальном состоянии и выбор какие именно тесты запустить на каждом изменении это две разные задачи, да у них есть некоторая похожесть.
Логику по выбору тестов которые запустить на ревью нужно написать и её нужно поддерживать. И я утверждаю, что это - сложная задача. Что-то можно сделать через юниты и тесты контрактов на уровне модуля. Можно построить граф зависимостей по коду и тестировать связанные модули (все тесты для этих модулей). Но кроме этого могут быть зависимости через базу/очереди.
Разработка сложных проектов требует практик: Менять интерфейсы между модулями только осмысленно, выкидывать не используемый код.
А синтаксическое слогоделение используется только для переносов в письменной речи
Когда набераешь текст, то можно и не переносить. С появление выравнивания по ширине это даже выглядит норм.
Cпецифика фрацузского, что там надо знать следующее слово, чтобы произнести текущее и даже переносы отдельных слов путают. Если бы переносили предложения только по ритмическим группам, было бы удобнее.
С тем чтобы запускать только нужные тесты, я не спорю.
Я просто не знаю инструментов, которые смогут тесты разделить правильно. А чтобы это делать на уровне людей, нужно чтобы все писатели тестов хорошо знали всю систему и последние изменения в ней.
Стоимость для бизнеса складывается из затрат на поддержание какие тесты запускать при изменениях и пропущенные ошибки из-за того, что нужные тесты не запустили раньше.
Все эти тест-сьюты они критичны для ручного тестирования, потом, что оно не масштабируется. Для авто тестов можно достаточно быстро добавить железа.
Просто ускорить тесты намного проще. Это можно сделать один раз. При этом это может сделать даже человек, который не имеет глубоких знаний в бизнес логике и архитектуре этого проекта. Например человек который только пришёл на проект, как автор поста.
Но чтобы выйти за пределы России, надо совершить колоссальные шаги, которые мы делать не умеем - это надо признать честно.
Не надо говорить за всех, говорите за себя и свою копанию. Есть много примеров когда компании вышли за пределы. И еще больше людей которые создали компании уже за пределами.
Повторю (перефразируя) коммент под предыдущей статьёй: в многопоточном коде, если разные потоки будут использовать один экземпляр класса, любовь к манипуляциям с переменными объекта приведёт к большим проблемам.
У класса нет ни одного не статического публичного метода. Как его будет использовать разные потоки?
полностью опирается на ИИ-инструменты, привязывает свои навыки к стабильности энергосистемы и инфраструктуры. Достаточно сбоя техногенного, природного или военного и эти навыки обнуляются
Если отключить электричество то и у человеков будут проблемы с доставкой контента. А когда они пересядут за холст и масло, то при включении электричества будут проблемы.
Программку писать не надо, если метрика годная, то уже должна быть. Для Питона есть.
Это я ещё раз повторяю мысль, что сложность восприятия человеком кода является субъективной характеристикой.
Вполне можно. Вложенные условия будут сложней плоских условий. Одна функция на 1000 строк сложнее десяти по сто. Ну и по ней не читаемость оценивают, а потенциально проблемные места: метод или функцию.
Мы точно говорим про автоматический запуск тестов на CI на каждый pull request?
Автор решал проблему именно эту проблему.
То никаких проблем собрал release notes,
Выглядит так, как будто у вас есть релизы и вы гоняет тесты перед датой релиза. Это проигрышная стратегия для бизнеса. Хорошо когда CICD и между началом работы и деплоем в прод происходит пара часов. Это правда будет подороже создания хороших тестсьютов.
Определение юнит тестов у автора достаточно широкое: тесты которые можно написать на фреймворке у которого есть unit в названии.
Я предпочитаю разделять юнит тесты и прочие тесты (интеграционные, компонентные, изоляционные). Границы всё равно несколько размыты и для каждого проекта нужно решать самому.
Юнит тесты, это что-то простое, без моков (но с заглушками), без соединений с базой, привязаны к конкретным классам и функциям, в том числе и внутренним, обычно чистым. Фокус тут на куске кода и его покрытие. Их жизненный цикл связан с их юнитом. Поменялся юнит, поменялись тесты, не поменялся, тесты должны продолжать проходить.
В месте где я сейчас работаю, всё остальное зовётся изоляционные тесты. И e2e с моками и тестирование отдельных модулей с моками. Сложность и хрупкость тут частые гости.
Эти две группы тестов требуют разного подхода, чистые юниты очень дешёвые в написании и поддержке и позволят быстро отлавливать часть проблем. Пирамида тестирования она как раз об этом.
И что можно класть болт на безопасность при работе в финтехе.
Всего 87,6 часов недоступность в год.
Тут да, но даже простая задержка доступности во внутреннем хранилище может помочь. Ну и если все зависимости идут через своё хранилище, можно быстро отключить зависимость.
За 25 лет можно и связи построить. Да и рекрутёры будут за вами бегать, а не вы за ними. Состаявшимся специалистам легче, чем начинающим.Да и рынок сейчас не в самой лучшей форме.
Остаётся только реклама.
В общем ничем, кроме моментов с законом. Всякие страховки, отчисления, налоги. Всё зависит от законодательства обоих стран.
Мне кажется мы о разном говорим. Поддержание тестов в актуальном состоянии и выбор какие именно тесты запустить на каждом изменении это две разные задачи, да у них есть некоторая похожесть.
Логику по выбору тестов которые запустить на ревью нужно написать и её нужно поддерживать. И я утверждаю, что это - сложная задача. Что-то можно сделать через юниты и тесты контрактов на уровне модуля. Можно построить граф зависимостей по коду и тестировать связанные модули (все тесты для этих модулей). Но кроме этого могут быть зависимости через базу/очереди.
Разработка сложных проектов требует практик: Менять интерфейсы между модулями только осмысленно, выкидывать не используемый код.
Когда набераешь текст, то можно и не переносить. С появление выравнивания по ширине это даже выглядит норм.
Cпецифика фрацузского, что там надо знать следующее слово, чтобы произнести текущее и даже переносы отдельных слов путают. Если бы переносили предложения только по ритмическим группам, было бы удобнее.
> Если команды не знают свой продукт и не понимают к чему приведут их изменения, то грош им цена.
А какая у вас позиция в компании и какого размера проект (в количестве работающих над ним людей)?
С тем чтобы запускать только нужные тесты, я не спорю.
Я просто не знаю инструментов, которые смогут тесты разделить правильно. А чтобы это делать на уровне людей, нужно чтобы все писатели тестов хорошо знали всю систему и последние изменения в ней.
Стоимость для бизнеса складывается из затрат на поддержание какие тесты запускать при изменениях и пропущенные ошибки из-за того, что нужные тесты не запустили раньше.
Все эти тест-сьюты они критичны для ручного тестирования, потом, что оно не масштабируется. Для авто тестов можно достаточно быстро добавить железа.
Просто ускорить тесты намного проще. Это можно сделать один раз. При этом это может сделать даже человек, который не имеет глубоких знаний в бизнес логике и архитектуре этого проекта. Например человек который только пришёл на проект, как автор поста.
Не надо говорить за всех, говорите за себя и свою копанию. Есть много примеров когда компании вышли за пределы. И еще больше людей которые создали компании уже за пределами.
Вы будете себя вести лучше, чем до этого.
У класса нет ни одного не статического публичного метода. Как его будет использовать разные потоки?
Творить можно и без, но как вы монетизировать будете?
Если отключить электричество то и у человеков будут проблемы с доставкой контента. А когда они пересядут за холст и масло, то при включении электричества будут проблемы.
Программку писать не надо, если метрика годная, то уже должна быть. Для Питона есть.
Вполне можно. Вложенные условия будут сложней плоских условий. Одна функция на 1000 строк сложнее десяти по сто. Ну и по ней не читаемость оценивают, а потенциально проблемные места: метод или функцию.
Мы точно говорим про автоматический запуск тестов на CI на каждый pull request?
Автор решал проблему именно эту проблему.
Выглядит так, как будто у вас есть релизы и вы гоняет тесты перед датой релиза. Это проигрышная стратегия для бизнеса. Хорошо когда CICD и между началом работы и деплоем в прод происходит пара часов. Это правда будет подороже создания хороших тестсьютов.
Кажется, что вы применили подход не к месту, получили проблем от этого и поставили крест на технологии. Не надо так.
Мы вообще должны дискутировать про рефакторинг, а не уточнять требование к задаче поставленной не нам.