страха рефакторинга не было у людей?
это каждый раз что-то меняя, надо потом ждать чтобы все E2E прошли, для того чтобы убедиться что ничего не изменилось в поведении системы?

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

так а что дает изоляция, даже если мы поменяли одну строчку в одном классе, если у нас есть только E2E для проверки, что в итоге ничего не сломалось, это же долго?

Заходил на один проект, в котором один из сервисов содержал много нагенеренного кода. Тесты в том числе ) и они тестировали чуть больше чем ничего.
Со временем перелопачивали и делаем интеграционные тесты с testcontainers. Каждый тест - сценарий.
Так как система модульная и в ядре блокчейн то и он в тестконтейнерах запускается.
И изначально чтоб разрабатывать слои ближе к пользователю, пишется тест для блокчейна с последовательностями различных команд и транзакций для него в сервисе который ближе всех к блокчейну, выяснить специфику реализации уже апи для клиентов. Мобильным разработчикам , чтоб понять как генерить транзакции тоже помогает взглянуть на тест около ядра

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

Я ещё вопрос задам: как понимали что в E to E тоже нет багов?

Долго, но это и тренерует не допускать очевидных багов, наверное. Сложно сказать, надо рефлексировать.

Аналитика же?

Всякие диаграммки можно строить: data-flow, control-flow.

Я к тому, что баг в тесте может приводить к мнению, что все в порядке и можно деплоить. И ещё при таком подходе стоимость ошибки взлетает до небес. Мое имхо

Это всё равно, что тренироваться по бразильской системе, боясь разбить окно.
С юнит-тестами фидбэк-луп быстрее и меньше когнитивная нагрузка по сравнению с дебагом глазами, дебаггером или логами

Тоже самое можно сказать про баг в unit-тесте 🙂

Я себе слабо представляю как можно разрабатывать более менее серьёзный проект и не писать unit тесты. Не потому что так кто-то сказал и это модно, а потому что мы все ошибаемся и я не верю своему коду пока не проверю его от и до.

Я не призываю отказываться от ее тестов, я за заявку юнит, ее, ручное.

Ну для логики сложнее чем assertEqual(sum(2,2),4) согласен, тесты нужны. Но если половина методов это расчёты из серии "возьми значение из этого столбца и умножь на значение из другого столбца" - то смысл в них?)

Ну не знаю, смотря что умножаем. В финтехе можно нормально наумножать, например)
Для 2х2 не надо конечно, но и что-то давно такого кода не писал

Юнит-тесты это хороший способ документации кода и проверка на совместимость ожидаемого поведения или результата тестируемого юнита или функциональности.
Однако юнит-тесты не гарантируют полной работаспособности системы, которая состоит из этих юнитов.
Для проверки на совместимость работаспособности целой системы пишутся интеграционные тесты.

По просьбам трудящихся, которые не хотят светить своим мнением в чате - анонимный формуляр
https://forms.gle/9YprgbD7swr2sZrt7

Спасибо за ваши мнения!