Давай, тестируй базу

а что у вас интеграционные тесты делают?

курят в курилке, обсуждают башара асада

т.е у вас только юнит тесты и полная изоляция?

есть чек контрактов, но он встроен в механизм взаимодействия

Сергей, вы почитайте за разницу между юнит, акцептанс и интеграцией

есть чек контрактов, но он встроен в механизм взаимодействия

все по контрактам в полной изоляции от внешнего мира?

накурено здесь, проветрите

а если внешнего мира много, т.е в проекте преобладает инфраструктура вместо бизнес логики?

то проект тестировать не нужно?

накурено здесь, проветрите

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

себя пожалей, ты читаешь и не понимаешь

ты мне хоть на один вопрос ответь, понимающий человек

пиздаболить особо ума не нужно

следующий

ну там хорошие вопросы были подняты, на самом деле

я давно о них задумывался но идеального решения не нашел

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

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

Или из фикстур

мы не чистим, а засираем тестовую базу да и все да, я проблему общую понимаю.

Или из фикстур

а если нужно много связанных данных?

Много связей или много данных?

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

если у тебя много бд, это немного другая опера, называется так себе архитектура

в идеале у сервиса должна быть одна причина изменить данные

если сервис дергает несколько бд в сценарии - это god like architecture

если у тебя много бд, это немного другая опера, называется так себе архитектура

а ты архитектор я смотрю?

Сережа, иди у мамки своей спроси

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

Ну так поддерживать фикстуры

Сережа, иди у мамки своей спроси

откуда такие долбоебы берутся?

откуда такие долбоебы берутся?

ответ в предыдущем ответе

Ну так поддерживать фикстуры

вариант с поддержкой дампа проще

Что за агрессив. Будьте культурны. Вы же девелоперы а не Птушники.

вариант с поддержкой дампа проще

Дамп может быть слишком большим.

Надо будет писать скрипт его уменьшающий и один фиг поддерживать же.

дамп можно снимать с продакшен базы, по нужным таблицам. 0 затрат в поддержке

Для тестов 15 минут грузить только дамп - это оверкилл же.

для интеграционных и выше это ок в принципе

Как уж 0? Е ли он снимает что-то?

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

надо попробовать оба варианта, пока еще прикидываю как это будет проще держать

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

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

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

Фикстуры нереально поддерживать, при нормальном наборе тестов

Фикстуры нереально поддерживать, при нормальном наборе тестов

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

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

Проверки выборок, флаш такое себе)

долго вы его терпели О.о

я его еще не банил)

что может быть лучше)

обоснуй)

а, он живой ещё

тебе разжевали немалый объем опыта выше

годика два работы с системой, которая имеет очень много интеграций с внешними апи

я не увидел там конкретики от тебя. тебе @mkusher задавал четкие вопросы, от которых ты уходил

ты чет там увидел про изоляцию, и давай тупо не по теме че-то пушить

да мне надоело просто, у него все должно быть с базой

тестируешь базу - тестируй

Лол

просто вместе с базой приходит еще один гемор с ее поддержкой

нужно иметь конфиг стенда

Где я писал, что все должно быть с базой?)))

у тебя где-то на границе там какие-то коннекты в бд

которые не покрыты тестами

про базу ты начал

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

ERROR: S client not available

тестировать провод на то, что он провод

лихо ты с базы на провод прыгаешь

бд выполняет две функции выдавать сохраненное и сохранять

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

и да, провода тоже разные бывают

у которой можно проверить вызов определенных функций обозначающих сохранение

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

дбал или орм или все вместе

да вообще ничего не тестируй

зачем

код без тестов хорошо живет

только недолго

ну это я по твоему опыту уже понял

Ребят у меня вопрос. Как сделать блок из 2х радиокнопок ChoiceType же в параметрах 'choices' => [ 1 => 1, 2 => 2, ], и основной вопрос как задать ему шаблон для рендера свой

Сережа, ты такой молодец у мамы, анализируешь опыт

ты в каком классе?

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

Сережа, ты такой молодец у мамы, анализируешь опыт

нахуя на личности переходить?

чё как хуйло то быть

ежик, так он за опыт начал)

кажется в середину холиварчика неудасно попал )

дбал или орм или все вместе

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

есть такая методология позволяющая упрощать дизайн

называется TDD, если мокаешь слишком много, это означает лишь одно - неверно разделена ответственность в модулях

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

для каждой внешней апишки у нас адаптер, который предоставляет разделяемый интерфейс

получить данные, отдать данные

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

консультации за деньги)

есть такая методология позволяющая упрощать дизайн

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

код написан по канонам тдд?

эт как