а по другому хз как сделать

А в коде приложения у вас тоже слипы стоят?

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

Если тесты не тестируют непосредственно работу репликации то это будет даже вредная имплементация.

А в коде приложения у вас тоже слипы стоят?

в коде нет, в коде сразу после создания не дёргается на чтение, дёргается через 1-2 секунды, а этого времени хватает для синка мастера и слэйва

Начни с целей тестирования.

цель, протестировать релиз

Если тесты не тестируют непосредственно работу репликации то это будет даже вредная имплементация.

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

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

Начнете искать ошибку в коде, потратите кучу времени.

А если есть набор тестов которые тестируют только бизнес-логику на максимально цельном стенде (без реплик и других сетевых сервисов), то вы будете уверены что сам код написан правильно, и уже тогда можно гнать тесты с примесью инфраструктуры.

Начнете искать ошибку в коде, потратите кучу времени.

Или перезапустите тест на тех же данных, он пройдет и все выдохнут.

потому что все понимают, что false negative падения - нормальная история.

А если есть набор тестов которые тестируют только бизнес-логику на максимально цельном стенде (без реплик и других сетевых сервисов), то вы будете уверены что сам код написан правильно, и уже тогда можно гнать тесты с примесью инфраструктуры.

И того вам надо мейнтейнить два/три/четыре набора тестов вместо одного, который тестировал бы production like работу сервиса.

И того вам надо мейнтейнить два/три/четыре набора тестов вместо одного, который тестировал бы production like работу сервиса.

Ну да, это называется SRP

У вас какое-то больное представление об SRP.

NO U

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

Это примерно как мейнтейнить отдельный набор тестов под каждый браузер.

Там про то что тесты проверяющие бизнес логику не должны еще отвечать за косяки инфраструктуры.

А как это все мейтейнить - вопрос отдельный уже. Возможно стоит написать просто тест который тестирует запись любых искусственных данных с репликой. + добавить задержки искусственные.

у меня на тесте 2 аплликейшен экспресс ноды JS фреймворка

ставить их продакшн-лайк на 8 - нет никакого смысла

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

Там про то что тесты проверяющие бизнес логику не должны еще отвечать за косяки инфраструктуры.

Бизнес логика завязана на инфраструктуру. Тестировать одно в отрыве от другого можно и нужно, никто не спорит. Это не даст вам никакого понимания того, как будет работать End to end.

> Бизнес логика завязана на инфраструктуру. Это утверждение - оно обобщенное или про что? Всегда завязана? При любых условиях? Или в нашем конкретном обсуждаемом примере? По другому быть не может? Гексагональная архитектура миф?

> Бизнес логика завязана на инфраструктуру. Это утверждение - оно обобщенное или про что? Всегда завязана? При любых условиях? Или в нашем конкретном обсуждаемом примере? По другому быть не может? Гексагональная архитектура миф?

покажи мне полноценную гексагональную архитектуру в реальном проекте, а не во влажных мечтах архитекторов

да, инфраструктура очень важна и тестировать лучше всего ближе к продакшн-инфраструктуре.

покажи мне полноценную гексагональную архитектуру в реальном проекте, а не во влажных мечтах архитекторов

Полноценная врядли есть, но для любой части этой архитектуры найдется такой проект который эту часть имплементирует ;)

Вот у нас например инфраструктура в амазоне сидит и конечно мы не строим аналогичную тестовую. Это не наш уровень ответственности и сделать мы ничего не можем. Мы тестируем просто бизнес логику проектов на одной маленькой виртуалке.

Полноценная врядли есть, но для любой части этой архитектуры найдется такой проект который эту часть имплементирует ;)

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

это не всегда возможно и не всегда оправдано, но лучше

Согласен

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

Ну то есть утверждение странное: лучше, но не всегда :)

попытка "продакшн-лайк" тестировать абстракцию конфигурации сервера - значит ставить под сомнение труд других 3rd party сервисов.

согласен с Павлом

Ну тут все с какой-то своей колокольни правы.

Ну вот в моем случае вообще не вижу смысла строить тестовое окружение на 30ти инстансах и кучей всяких VPC правил маршрутизации и т.п. Это тогда надо еще парочку людей на фултайм брать.

попытка "продакшн-лайк" тестировать абстракцию конфигурации сервера - значит ставить под сомнение труд других 3rd party сервисов.

если у тебя честный продакшон лайк инстанс – ты защищен от ситуаций, когда у тебя забыли на продакшон доехать зависимости/нужные миграции/неправильный роутинг/неправильные хедеры/что угодно

но иногда дешевле в проде поправить, чем все это накручивать и тестировать

если у тебя честный продакшон лайк инстанс – ты защищен от ситуаций, когда у тебя забыли на продакшон доехать зависимости/нужные миграции/неправильный роутинг/неправильные хедеры/что угодно

это все здорово и прекрасно, если ты делаешь магазин на диване

нет

приди к продакту и скажи " мы хотим продакшн-лайк тестировать, дайте нам фьюжны, 1тб РАМ и 32ядерный процессор"

если у тебя железозависимые вещи – как еще?

приди к продакту и скажи " мы хотим продакшн-лайк тестировать, дайте нам фьюжны, 1тб РАМ и 32ядерный процессор"

А в чем, собственно, проблема?

Если ты можешь обосновать профиты от такого инстанса - выдадут.

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

изначально вопрос был в том, что ты хочешь тестировать в тестовом контуре: как шардинг разработчики настроили?

Бизнес, продакшен инстанс которого стоит сто тыщ баксов, в 99.9% случаев может себе позволить ещё сто тыщ, если поймет зачем это надо. Задача команды разработки понять, нужно ли это и если нужно - донести эту мысль, со всеми необходимыми аргументами. The end.

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

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

вот только тут не надо настолько утрировать

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

Ох, опять категоричность запредельная.

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

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

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

Есть пруфы, или ты как всегда просто влажно фантазируешь?

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

давайте не будем приравнивать "пофигу на чем" с "не продакшн лайк"

продакшн лайк это класс эквивалентности, не больше и не меньше

а нагрузочное тестирование, например, как делать если у вас нет денег на второй сервак прод лайк?

никто не говорит что инстанс должен быть таким же

а нагрузочное тестирование, например, как делать если у вас нет денег на второй сервак прод лайк?

в проде очевидно

в проде очевидно

пусть юзеры и тестируют ))

Ну вот допустим запилил ты реплику на тестах. Тест у тебя в один момент упал. Ты запустил второй раз и он не упал. Что из этого следует? А ничего.

а нагрузочное тестирование, например, как делать если у вас нет денег на второй сервак прод лайк?

делали в проде, в те моменты, когда был наименьший (у нас - нулевой) процент посещаемости продукта.

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

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

Ну вот допустим запилил ты реплику на тестах. Тест у тебя в один момент упал. Ты запустил второй раз и он не упал. Что из этого следует? А ничего.

Из этого следует, что надо добавить больше логирования в тестах, что бы понимать, где и почему он упал.

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

ERROR: S client not available

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

Если, например, объемы данных на деве и проде качественно отличаются, то это только вопрос времени когда вы будете поднимать продакшен со словами "ой, а на деве работало".

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

это не наезд – просто юниттесты не заменяют функциональное тестирование

Если, например, объемы данных на деве и проде качественно отличаются, то это только вопрос времени когда вы будете поднимать продакшен со словами "ой, а на деве работало".

+1

Юниттесты отличная штука. Они проверяют, что код выполняется более-менее предсказуемо.

Они не говорят о работоспособности продукта примерно ничего, в этом проблема.

То есть прям ничего ничего? Может их тогда выкинуть?

Если, например, объемы данных на деве и проде качественно отличаются, то это только вопрос времени когда вы будете поднимать продакшен со словами "ой, а на деве работало".

При пропорциональной разнице производительности такого эффекта не дожно быть

При пропорциональной разнице производительности такого эффекта не дожно быть

Проблема в подсчете "пропорциональности".

Т.к. производительность - история не линейная и количество точек отказа тоже довольно велика.

Проблема в подсчете "пропорциональности".

Есть такая проблема, да.

То есть прям ничего ничего? Может их тогда выкинуть?

Я понимаю, что читать буковки сложно. Повторю ещё раз. Юнит тесты проверяют работоспособность кода. Работоспособность кода != работоспособности приложения. Одно не заменяет другое, они используются в разных условиях и для разных целей.

Сложно читать категоричные обобщенные утверждения и взаимоисключающие параграфы. А буковки норм.

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

Они не говорят о работоспособности продукта примерно ничего, в этом проблема.

Если юнит тесты падают, из этого следует что продукт неработоспособен. nuff said.

нет, не следует)

Нет, не значит.

а что считает "работоспособен"? кривой билд программы который выпустили разработчики - принес деньги

при этом забили на красные "пока что" юниттесты

работоспособный ли он?

Если продукт выполняет бизнес-функцию -> работоспособен.

слишком много если. Юнит тест может быть написан на критическую ф-сть

We need to go deeper. Где критерии выполнения бизнес-функции? ?

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

Это не значит, что юнит тесты не нужны или не приносят пользы. Юнит тесты это быстрый healthcheck приложения + пара дополнительных приятностей в процессе их написания и поддержки. Их падение сигнализирует, что _возможно_ вы что-то сломали, но их прохождение категорически не говорит об обратном.

Ты лучше скажи, поднимать ему реплику на тестах или нит?

Я уже ответил выше. Если есть высокий багрейт на уровне "локально работает, а продакшен в огне" - то имеет смысл об этом задуматься, оценить cost vs value и решить. Если на текущий момент таких проблем нет - то поднимать реплику ради реплики так себе идея.

?

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

Шайтаны, у нас из-за вас сейчас залагал прод.

проявились слабые места. Это же хорошо ?

А кто-то пробовал делать интеграцию Джиры, Зефира и Дженкинса для записи автотестов через Зефир и дальнейшей автоматической сборки и прогона?

Зефир как джироаддон или как отдельный инстанс?