Не с БД. Вместо репо, которая пошла бы в БД имитация репо, которая пойдёт в ОЗУ

Я не очень понимаю, к чему ты ведёшь. То — не так, это — не так. А как "так"-то?:)

Не писать тесты, надеясь на статический анализ?

ну то есть например если у тебя в базе uniq constraint на поле то ты будешь имплементацию этого дублировать в своем "репозитории"?

а где коммит транзакции будет?)

я писал выше все

Я отдельно протестирую реальный репо с запуском реальной БД. Но это будут не тесты сервиса, а тесты репо

в данный момент я привязался к твоему определению black/white box тестированию - просто потому что это популярное заблуждение

я так понимаю что ты просто не пишешь приемочных тестов.

Конечно напишу

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

Такое чувство, что ты думаешь, что если я напишу юниты, то не напишу приёмочные и наоборот. Приёмочных тестов со всеми возможными исходами будут миллионы

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

Если один приёмочный закрывает все исходы, то юниты не нужны

так же как сервисы и репо разделяем везде потому что "ну а вдруг"

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

Я за здравый смысл перед карго культом. Но практика показывает, что часто "здравым смыслом" прикрывают совсем нездравые вещи

а так делать не надо? имею ввиду разделять на слой работы с данными (БД грубо говоря) и слой самой логики?

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

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

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

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