Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Сделать для БД мок, проверяющий скрипты миграции — no way.

Мок нужно делать не для БД, а для библиотеки миграций. И это не очень сложно.

НС>все равно есть тесты, которые на любой ПР слишком дорого. Их обычно гоняют по расписанию.

Вот это и есть зло. Такой подход приводит к тому, что на выявление и фикс ошибок уходит намного больше времени, нежели если бы их прогнать на ПРе. И в больших конторах обычно такие баги попадают отнюдь не на того, то породил баг. Теряется связь между ПРом и багом.

На мой взгляд лучше все тесты гнать на ПРе, а те что долгие просто гнать как-бы после заезда ПРа. Ну или надо делать систему, которая будет искать ПР в котором появилась ошибка. Иначе это приводит к сильным непроизводительным затратам. А учитывая, что тесты (особенно интеграционные) могут флакать — это превращается вообще в недетерминированное действо и кашмар.

НС>Теоретически. А на практике знал бы ты, сколько раз и какое количество времени мне спасли хотя бы минимальные тесты на внешние зависимости.

Тесты на внешние зависимости, они же интеграционные тесты, несомненно нужны. Но их должно быть минимум, так как они по определению самые медленные и самые ненадежные (особенно если проверяется интеграция с внешними сервисами).

У нас, например, тоже не выходит гнать все тесты на каждом ПРе. К тому же наши залудили Монорепу и в результате в мастер лезут комиты от разных продуктов, а иногда и не от продуктов вовсе. По этому придумнны разные BvtPvt и Smoke, которые идут совершенно независимо от ПРов. Баги с них могут завестись получить третий приоритет и по несколько месяцев висеть без разбора. А потом такое говно сваливается на тебя и ты занимаешься не отладкой, а игрой в Шерлока Холмса расследуя случившееся. В результате фикс баги вместо нескольких часов превращается в день или многодневный неблагодарный труд.

Наверно если ты делаешь сайт командой в 10 человек, это не особая проблема. Но когда в разработку вовлечены хотя бы сотни людей — это еще та боль.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Сделать для БД мок, проверяющий скрипты миграции — no way.

Мок нужно делать не для БД, а для библиотеки миграций. И это не очень сложно.

НС>все равно есть тесты, которые на любой ПР слишком дорого. Их обычно гоняют по расписанию.

Вот это и есть зло. Такой подход приводит к тому, что на выявление и фикс ошибок уходит намного больше времени, нежели если бы их прогнать на ПРе. И в больших конторах обычно такие баги попадают отнюдь не на того, то породил баг. Теряется связь между ПРом и багом.

На мой взгляд лучше все тесты гнать на ПРе, а те что долгие просто гнать как-бы после заезда ПРа. Ну или надо делать систему, которая будет искать ПР в котором появилась ошибка. Иначе это приводит к сильным непроизводительным затратам. А учитывая, что тесты (особенно интеграционные) могут флакать — это превращается вообще в недетерминированное действо и кашмар.

Ну и главное, если есть выбор сделать интеграционный тест или обойтись модульным юнит-тестом, лучше выбрать последнее даже если придется потратить время на сложный Мок. Ведь последний точно можно добавить в ПР и он будет ловить регресс сразу.

НС>Теоретически. А на практике знал бы ты, сколько раз и какое количество времени мне спасли хотя бы минимальные тесты на внешние зависимости.

Тесты на внешние зависимости, они же интеграционные тесты, несомненно нужны. Но их должно быть минимум, так как они по определению самые медленные и самые ненадежные (особенно если проверяется интеграция с внешними сервисами).

У нас, например, тоже не выходит гнать все тесты на каждом ПРе. К тому же наши залудили Монорепу и в результате в мастер лезут комиты от разных продуктов, а иногда и не от продуктов вовсе. По этому придумнны разные BvtPvt и Smoke, которые идут совершенно независимо от ПРов. Баги с них могут завестись получить третий приоритет и по несколько месяцев висеть без разбора. А потом такое говно сваливается на тебя и ты занимаешься не отладкой, а игрой в Шерлока Холмса расследуя случившееся. В результате фикс баги вместо нескольких часов превращается в день или многодневный неблагодарный труд.

Наверно если ты делаешь сайт командой в 10 человек, это не особая проблема. Но когда в разработку вовлечены хотя бы сотни людей — это еще та боль.