D
Size: a a a
2020 April 27
E
да. проверено. часть моками можно закрыть, но далеко не все. джойны уже не закроешь.
????
Это почему?
Это почему?
DP
да. проверено. часть моками можно закрыть, но далеко не все. джойны уже не закроешь.
не надо, чтобы джойны проникали на уровень бизнес-логики. не надо. иначе нам всем труба
AK
да и сейчас грешат, то тут то там хранимки всплывают
Хуже всего когда начинают смешивать. Вот тогда получается просто каша. И доказательств этому просто море и каждый с этим сталкивался думаю.
RC
????
Это почему?
Это почему?
ну а чем ты движок джойнов заменишь? заранее рассчитанным датасетом в переменной?
RC
не надо, чтобы джойны проникали на уровень бизнес-логики. не надо. иначе нам всем труба
мы обсуждаем чем заменить sql.DB. как же без них? а еще транзакции, вот ведь беда :)
DP
мы обсуждаем чем заменить sql.DB. как же без них? а еще транзакции, вот ведь беда :)
как оказалось - самым простым способом решить проблему является “не втаскивать *sql.DB в код бизнес-логики, написать прослойку”
AK
Надо просто запретить разрабатывать на Go бизнесовые приложения. Только инфраструктуру и только перекладывание байтиков. Тогда все холивары моментально закончатся.
RC
У меня есть метод у интерфейса Repo
GetAccount(ctx, id) (*User, err)
Инфа о юзере раскидана в несколько таблиц
Бизнес логика об этой знает? Нет, ей насрать, она дергает аккаунт по ID и срать что там, джоины или не джоины
GetAccount(ctx, id) (*User, err)
Инфа о юзере раскидана в несколько таблиц
Бизнес логика об этой знает? Нет, ей насрать, она дергает аккаунт по ID и срать что там, джоины или не джоины
тогда это вопрос не про мок sql.DB, а про мок GetAccount
МП
Если у тебя в бизнес логике будет торчать прокидывание *sql.DB, как ты его замокаешь? Как ты протестируешь логику без подключения к реальной бд? Поднимаешь тестовую БД? У тебя 450 тестов только в слое бизнес логики, ты не думаешь, что мягко говоря, это будет не удобно?
У меня то, чего Даниэль так страшно баица - тригггры, сторед-процедуры, которые делают львиную часть бизнес логики. Каким образом ты предлагаешь мне мокать их функционал, переписать мускул? И потом - на кой хрен мне тестить sql.DB ? с этой стороны обычно проблем нет, а если и возникают - фиксятся мгновенно
DP
тогда это вопрос не про мок sql.DB, а про мок GetAccount
а вот его замокать вообще нет проблем
E
тогда это вопрос не про мок sql.DB, а про мок GetAccount
Берешь такой gomock и генеришь мок
RC
как оказалось - самым простым способом решить проблему является “не втаскивать *sql.DB в код бизнес-логики, написать прослойку”
верно. но при этом надо понимать, что работа с базой останется непротестированной.
DP
Мимо Проходящий
У меня то, чего Даниэль так страшно баица - тригггры, сторед-процедуры, которые делают львиную часть бизнес логики. Каким образом ты предлагаешь мне мокать их функционал, переписать мускул? И потом - на кой хрен мне тестить sql.DB ? с этой стороны обычно проблем нет, а если и возникают - фиксятся мгновенно
я боюсь, коллега, не этого всего, а того, что мне придется ваш код читать и модифицировать. и хорошо, если вы к тому времени уже покинете компанию. а если нет - я могу и сесть за тяжкие телесные :)
E
верно. но при этом надо понимать, что работа с базой останется непротестированной.
Покрыть тонкий слой работы БД можно интеграционным тестом, ведь там логики нет никакой и покрыть такое не проблема
RC
Покрыть тонкий слой работы БД можно интеграционным тестом, ведь там логики нет никакой и покрыть такое не проблема
если три таблички и пять запросов то конечно не проблема
DP
а если 30 таблиц и сотня запросов - тем более нельзя это допускать до кода бизнес-логики
МП
я боюсь, коллега, не этого всего, а того, что мне придется ваш код читать и модифицировать. и хорошо, если вы к тому времени уже покинете компанию. а если нет - я могу и сесть за тяжкие телесные :)
А вот теперь поясните мне коль скоро вы такой грозный - на кой хрен использовать интерфейс, который будет реализован ОДИН раз. Тестовая бд есть, поднять её проблем нет (быстро), мокать не надо - чяднт?