суть в том что логи и тесты писать итак придется, а дебаггер можно обойти стороной

И потом, я знаю из паления тестов, что алгоритм некорректен

Мне интересно посмотреть в кишки и понять почему именно алгоритм некорректен. И вот дебаг просто рулит и бибикает

Логи в тестах полезны, я их использую, но:

1.  Не всегда понятно куда их втыкать
2. Их не всегда удобно воткнуть – стандартная библиотека и сторонние пакеты например

ну про сторонние либы скажу одно, у меня никогда с ними проблем не было. Бывало форкали и допиливали под свои нужды, но таких кейсов парочка за несколько лет

а куда втыкать всегда понятно. На логические развязки в коде

Да, дебаггер не обязателен, но очень очень удобен

Почему это не тест а черти знает что? Если говорить о чистых функциях. Детерминированные функции тоже могут содержать в себе вызовы других детерминированных функций. И если вы их не мокаете, а тестируете их все неявно через вызов какой-то одной, это и есть интеграционный тест, потому что вы не изолировали функцию, вы просто дергаете половину мира и смотрите что она вернет. А вся суть юнит-тестов в изоляции.

Почему "черт знает что"? Это тестирование взаимодействия нескольких сущностей. Т.е., интеграционный тест.

Представь что у тебя конкурентная логика и очень много ветвлений

Сколько времени ты будешь вставлять логи? По хорошему надо делать отдельную инфраструру для дебаг режима – это нормально и правильно для бизнес логики, но если логика пакета не предполагает io, то это становится просто усложнением кода, которое 90% времени не используется

но мне же все равно нужен тест, который покроет все варианты, и всем проверит корректность.

так что логи случатся сами собой

Тест нужен и должен покрывать как можно больше комбинаций ветвлений

Но покрыть все нужные места логами – это совсем другой коленкор и может быть нетривиальной задачей

Для покрытия ветвлений тебе надо управлять входными данными тестами

я поддерживаю log-driven development, у меня почти нет тестов (это херово, но речь о петпроджекте, на который времени не 40ч в неделю за зп)

начали с 1000 строк кода, уже под 20к, логи понатыканы везде где нужно через zap и обертки

как используем? Пишет юзер, что у него что-то пошло не так, мы берем userId и находим его сессии, далее по сессиям все что происходило и где оборвалось
что логгируем? user/session айди, входные данные, результаты обработки — в итоге всегда легко воспроизводится в любых окружениях, порой с планшета видно как и что 🙂 Ну и конечно prometheus/postgres метрики чтобы глобально что-то видеть и анализировать

не-не-не

или у тебя функцию переписывать надо, чтобы она была тестируемой, или провалившийся тест однозначно указывает, что пошло не так

вариант “давайте отладим, а тесты не будем писать” я не рассматриваю

Кажется, "нужные" места имеет смысл покрывать логами во время кодинга, а не после.

впрочем - мне все ясно :)

я не люблю отладку, и потому не пользуюсь отладчиком

те, кто любят отладку - пользуются

в итоге как-то и без дебаггера и тестов без багов неделями по 30-150 рпс держится и ок

нет, они по определению чистой функции не являются "зависимостями". Нужно ли тестировать более низкоуровневые чистые функции, вызываемые более высокоуровневой, зависит от требуемой степени детализации. Теоретически можно написать тесты для всех функции, иногда достаточно для одной - если quick check показал её правильность, то из этого следует правильность и всех зависимых

Для покрытия логами нужно пройтись по каждому пути и ветвлению

Если используются сторонние библиотеки – это становится очень однообразной работой с низким качеством выхлопа

а можно на это посмотреть?