Все эти рекомендации - полное фуфло. У вас в проде тоже тесткейчы изолированные? Проверять то, что у вас EF работает пусть проверяют мейнтейнеры EF. А в реальной жизни нужны реальные тесткейсы которые есть в реальной базе. Там может быть разный порядок данных, другая статистика на индексах и прочие реальные вещи и тестировать нужно именно это. Все реальные кейсы с БД которые я исправлял никак не проявлялись на тестовой БД

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

ну это ты больше про перф говоришь, + есть шанс что-то сломать

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

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

Никто не говорит про боевую БД, никто не мешает нагенерить данные. Просто данных должно быть много и заниматься этим для каждого кейса - такое себе

ааа, в этом смысле

тогда +

Если 1 запрос может нести проблемы, то должна быть квалификация + код ревью

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

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

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

так он говорит один раз наполнить)

Вот приведи пример хотя бы 1 тест кейса из этих 22 минут

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

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

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

Ну то, что я видел чаще всего - это таблица со словарем в 6 столбцов локализированных значений типа en, es, fr, de, cn, jp

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

Но твой конкретный кейс с поиском в таблице локализации будет очень удобно делать