Информация об изменениях

Сообщение Re[9]: имитация окружения от 07.04.2023 18:57

Изменено 07.04.2023 19:01 VladD2

Re[9]: имитация окружения
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>И что ты там сможешь проверить? только сам факт вызова? А что насчет проверки самих скриптов?


Проверить ты сможешь идентичность структур БД полученных в следствии миграции и прямого создания БД. Сами скрипты и есть код миграции вызывающие АПИ миграции.

На фиг это нужно — спрашивай у автора темы.

НС>Вынужденное зло. Если ПР будет прогоняться часов 6 — это еще хуже.


Нет. Это будет лучше. У нас при таком уродском подходе ПР идет часа 3-4 (на адско быстром железе).

НС>Именно это я и написал.


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

НС>С чем ты споришь?


Это ты споришь. Я всего лишь заметил, что при выборе между интеграционными и модельными нужно всегда выбирать последние. Так что если если стоит выбор написать сложный мок или сделать менее сложный интеграционный тест нужно выбирать создание сложного мока. Иначе рано или поздно ты придешь вот к такому говниющу когда тесты идут хрен знает когда и найти ПР который привел к регрессу становится не самой простой задачей требующей много времени квалифицированных программистов. Время железа всегда дешевле времени людей.
Re[9]: имитация окружения
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>И что ты там сможешь проверить? только сам факт вызова? А что насчет проверки самих скриптов?


Проверить ты сможешь идентичность структур БД полученных в следствии миграции и прямого создания БД. Сами скрипты и есть код миграции вызывающие АПИ миграции.

На фиг это нужно — спрашивай у автора темы.

НС>Вынужденное зло. Если ПР будет прогоняться часов 6 — это еще хуже.


Нет. Это будет лучше. У нас при таком уродском подходе ПР идет часа 3-4 (на адско быстром железе).

НС>Именно это я и написал.


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

НС>С чем ты споришь?


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