Задача автоматического тестирования никогда и не была в гарантии отсутствия багов. А в достижимости этой цели в принципе. В отличии от ситуации когда тестов вообще нет.
Если ваши тесты не дают информацию о зонах доступности кода (code coverage по простому), то ваши интеграционные тесты усложняют жизнь разработчику не давая ничего.
Если запуская ваши интеграционные тесты вы не можете поставить сервис на брекпоинт не делая ничего дополнительно (кроме запуска теста в IDE) - то ваши тесты не дают разработчику ничего.
Слой инициализации важный компонент интеграционного тестирования. И в этом плане достижимость эффективной работы в го такая же, как и в условной Java. Для этого не нужна магия. Для этого нужно научится - писать тесты для слоя инизициализации - потому что каждый такой тест в итоге становится интеграционным, оставаясь при этом, практически unit-тестом.
То что вам что-то кажется бессмысленным отражает ваш узкий взгляд на проблему. Как и тех, кто считают main очень удобной заменой DI контейнеру или ненужным к тестированию. В итоге ваш "простой" подход оказывается лишь более сложным и громоздким в поддержке и эксплуатации.
Мне вообще ничего не мешает иметь 100% codecov где угодно. С этим проблема почему-то только у любителей всё в main загружать.
Смысл есть всегда. По статистике где-то на 100-1000 строк кода (в зависимости от уровня исполнителя) есть 1 баг. Если у вас 2000 строк кода в мейне, у вас там минимум 2 бага да обнаружаться. Особенно при длительной поддержке. Особенно при высокой цикломатической сложности, которая свойственна авторам кода на go (максимально на что я выкрутил линтер в этом плане составляло - 1400, на минуточку).
В го нет аналога того что есть у эрланга с эликсиром, но руками можно собрать. Только не из main функции. Потому и неплохо инициализацию утащить чуть в сторону и использовать потом тем же способом, что вы и описываете.
Требует культуры, у любителей мейнов с ней беда увы.
В инициализации тоже возникает. Но тут есть ещё момент, что у го есть особенность технологическая - позволяющая запустить обычным test suite сервис с его интеграционными зависимостями. И когда у вас есть DI (даже ручной и статический) - то го позволяет проверить и это тоже.
Но борцы за main в го предпочитают 2000-3000 строк кода в одной функции написать и ловить проблемы не пробе.
Но тут проблема не в моках, а в большом блоке кода с большим числом зависимых вызовов. В го люди плохо умеют в декомпозицию и тестирование, так что не удивительно, что строгий экспект мока - мешает.
Бывают языки (например) новые без фреймворков. А есть ещё и задачи, для которых может и не быть фреймворков. И в обоих случаях неплохо бы их спродуцировать, например.
Умение писать работающий код - это необходимый навык для любого программиста. Однако, это навыки которые являются решающими на этапе джуниор и мидл разработчика. Когда мы говорим про senior, то уже подразумевается, что человек в него может хорошо, и его проверка по большому счета даже не требуется.
У меня тут был забавный диалог, с человеком из мира Java. Который удивлялся моим рассказам, о том, что в go никто не пишет unit-test'ы.
Большинство навыков, которые должны формироваться на этапа джуниора, отсутствуют у людей являющихся сеньор или принципиал инженерами в бигтехе, не говоря уж о тимлидах и техлидах.
Да, они умеют писать работающий код. В определенных ситуациях. И абсолютно не поддерживаемый, примитивный и многословный - просто посади людей в мир "без фреймворков" и оказывается, что у них нулевые навыки в организации, рефакторинге, структурировании, стандартизации, минимизации сложности.
Хочу отметить, что исключения бывают, но они редки. По моей оценке менее 10% команд и компаний смогли бы пройти мои стандарты качества и требований. А они ведь ещё и не очень высоки.
Моё изучение опенсорсных репозиториев на Rust и Go, в целом соответствует ожиданию - там качество исполнения - ещё ниже. И бигтех скорее роняет планку, чем держит её.
Разговор глухого со слепым. Вы моими же аргументами о некомпетентности разработчиков, пытаетесь оправдать некомпетентность.
В го есть строгое соглашение на распостранение паники. Можете продолжать вашу борьбу, но рекомендую вам перейти на котлин. Там ваши проблемы решены и даже нетив есть. Правда работает медленее, чем го. Пока медлнее.
А это вы определили, что не требуется или какое-то практическое исследование было?
Вполне себе нормальная история, когда получив (конкретную) ошибку, вы маршрутизируете код в другом направлении. В случае если код будет выкидывать panic - написание и поддержка такого кода усложнится на 2 порядка.
Относительно оператора в rust, я бы не сказал, что это прекрасное решение. Более того, я скажу, что оно отвратительное - почему у меня каждая строка кода вызывающего interop встала под вопрос? После шахмат и kotlin у меня предубеждение к такому подходу. Знаки препинания скорее показывают проблемы в коде, чем решают их.
Я бы сказал, что эта проблема должна решаться на уровне компилятора. Если в сигнатуре на стеке есть error возврат - то самим компилировать блок возврата для каждой строки где не написано "_" для ошибки.
Задача автоматического тестирования никогда и не была в гарантии отсутствия багов. А в достижимости этой цели в принципе. В отличии от ситуации когда тестов вообще нет.
Тут беда в разработчиках. DSL можно сформировать в го, но культ примитивизма приводит к тому, что делая "проще" получается сложнее.
Если ваши тесты не дают информацию о зонах доступности кода (code coverage по простому), то ваши интеграционные тесты усложняют жизнь разработчику не давая ничего.
Если запуская ваши интеграционные тесты вы не можете поставить сервис на брекпоинт не делая ничего дополнительно (кроме запуска теста в IDE) - то ваши тесты не дают разработчику ничего.
Слой инициализации важный компонент интеграционного тестирования. И в этом плане достижимость эффективной работы в го такая же, как и в условной Java. Для этого не нужна магия. Для этого нужно научится - писать тесты для слоя инизициализации - потому что каждый такой тест в итоге становится интеграционным, оставаясь при этом, практически unit-тестом.
То что вам что-то кажется бессмысленным отражает ваш узкий взгляд на проблему. Как и тех, кто считают main очень удобной заменой DI контейнеру или ненужным к тестированию. В итоге ваш "простой" подход оказывается лишь более сложным и громоздким в поддержке и эксплуатации.
Есть мой код и есть код уважаемых коллег. Если вам повезло работать исключительно с вашим кодом, искренне вам завидую.
Мне вообще ничего не мешает иметь 100% codecov где угодно. С этим проблема почему-то только у любителей всё в main загружать.
Смысл есть всегда. По статистике где-то на 100-1000 строк кода (в зависимости от уровня исполнителя) есть 1 баг. Если у вас 2000 строк кода в мейне, у вас там минимум 2 бага да обнаружаться. Особенно при длительной поддержке. Особенно при высокой цикломатической сложности, которая свойственна авторам кода на go (максимально на что я выкрутил линтер в этом плане составляло - 1400, на минуточку).
В го нет аналога того что есть у эрланга с эликсиром, но руками можно собрать. Только не из main функции. Потому и неплохо инициализацию утащить чуть в сторону и использовать потом тем же способом, что вы и описываете.
Требует культуры, у любителей мейнов с ней беда увы.
Вопрос весьма сложный. Я сам всегда недоумеваю, но тем не менее.
Самое маленькое что я видел 900 строк кода.
В инициализации тоже возникает. Но тут есть ещё момент, что у го есть особенность технологическая - позволяющая запустить обычным test suite сервис с его интеграционными зависимостями. И когда у вас есть DI (даже ручной и статический) - то го позволяет проверить и это тоже.
Но борцы за main в го предпочитают 2000-3000 строк кода в одной функции написать и ловить проблемы не пробе.
Всегда люблю спрашивать, люителей обычно в main всё создавать. Какой у них code coverage тестами их main'a?
самая популярная gomock: https://github.com/uber-go/mock
Но тут проблема не в моках, а в большом блоке кода с большим числом зависимых вызовов. В го люди плохо умеют в декомпозицию и тестирование, так что не удивительно, что строгий экспект мока - мешает.
Даже если эти примеры это пайлоад в ресте? Неужели в входном json'e нельзя подсунуть строку вместо числа?
Я про российский бигтех писал. Что там в FAANG, не могу сказать - тут сплошной карго культ.
Как это связано?
Бывают языки (например) новые без фреймворков. А есть ещё и задачи, для которых может и не быть фреймворков. И в обоих случаях неплохо бы их спродуцировать, например.
У меня тут был забавный диалог, с человеком из мира Java. Который удивлялся моим рассказам, о том, что в go никто не пишет unit-test'ы.
Большинство навыков, которые должны формироваться на этапа джуниора, отсутствуют у людей являющихся сеньор или принципиал инженерами в бигтехе, не говоря уж о тимлидах и техлидах.
Да, они умеют писать работающий код. В определенных ситуациях. И абсолютно не поддерживаемый, примитивный и многословный - просто посади людей в мир "без фреймворков" и оказывается, что у них нулевые навыки в организации, рефакторинге, структурировании, стандартизации, минимизации сложности.
Хочу отметить, что исключения бывают, но они редки. По моей оценке менее 10% команд и компаний смогли бы пройти мои стандарты качества и требований. А они ведь ещё и не очень высоки.
Моё изучение опенсорсных репозиториев на Rust и Go, в целом соответствует ожиданию - там качество исполнения - ещё ниже. И бигтех скорее роняет планку, чем держит её.
А вот сейчас обидно было, питон бы не смог интерпретировать код без знаков препинания в виде форматирования абзацами.
Разговор глухого со слепым. Вы моими же аргументами о некомпетентности разработчиков, пытаетесь оправдать некомпетентность.
В го есть строгое соглашение на распостранение паники. Можете продолжать вашу борьбу, но рекомендую вам перейти на котлин. Там ваши проблемы решены и даже нетив есть. Правда работает медленее, чем го. Пока медлнее.
А я пожалуй буду таков.
Это если его перехватили. Я буквально вчера на ревью человека попросил кетчер в первой строке короутины написать в дефёре.
И ответ "это вопрос чистоплотности" не принимаю, т.к. 99% разработчиков не способны написать больше 100 строк кода без бага.
А это вы определили, что не требуется или какое-то практическое исследование было?
Вполне себе нормальная история, когда получив (конкретную) ошибку, вы маршрутизируете код в другом направлении. В случае если код будет выкидывать panic - написание и поддержка такого кода усложнится на 2 порядка.
Относительно оператора в rust, я бы не сказал, что это прекрасное решение. Более того, я скажу, что оно отвратительное - почему у меня каждая строка кода вызывающего interop встала под вопрос? После шахмат и kotlin у меня предубеждение к такому подходу. Знаки препинания скорее показывают проблемы в коде, чем решают их.
Я бы сказал, что эта проблема должна решаться на уровне компилятора. Если в сигнатуре на стеке есть error возврат - то самим компилировать блок возврата для каждой строки где не написано "_" для ошибки.
это конечно прекрасно, но в итоге в го нет ни одного стека вообще. Т.к. враппится только один. И ошибка - не исключение, это не упавший код.
А в чём суть языка?