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

Это только говорит об ущербности (с т.з. srp) каноничного рейлс-вея)

вот такие портянки User.active.allowed_to_sign.page(5).per_page(10).all

это тавтология
есть тесты в AR/Arel которые проверяют что методы чейнятся, это работает и работает правильно
а если ты хочешь тестировать что `User.active.allowed_to_sign.page(5).per_page(10).all` возвращает 5 активных пользователей, которым можно залогиниться, в 5 страниц по 10 на страницу - то ты конфигурацию тестируешь, что программист нигде не опечатался. по сути пишешь 2 раза одно и тоже: в реализации и в тестах

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

Ну так я и пытаюсь объяснить, что можно ar рельсовый использовать как репозиторий 🙂 надо выполнить только 2 пункта
1. Работаем только через скоупы - никаких where
2. Прокидываем модель как зависимость-репозиторий

Все так

Мвц это lite-версия приложения, а дальше накручиваешь dlc, всё в порядке))

Просто изначально понял что претензия именно именно к чейну скоупов - в этом ничего плохого я не вижу. Если я не правильно понял претензию то сорян за кипишь😀

Не, тут смотри идея какая: у тебя сервис есть в котором вызывается чейн модели + обрабатывается результат. В случае юнит теста, тебе важно проверить логику обработки запроса в зависимости от пары случаев модели. А юнит тест покрывает контракты между сервисом и моделью

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

Не совсем, у мвс есть пара проблем, например: где валидации разные держать и бизнес логику

Никакие длс тебе тут не помогут

Хм, вроде нет, об этом не говорилось прямо явно

Длц - это все прочие слои приложения, что угодно, так что помогут) Хреново конечно, что dhh не дал нам универсальный космолёт и чтобы всё по solid, что поделать

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

вот пример

module ActivityMonitoring
  module Notifiers
    class UserEmail
      def self.call(...)
        new(...).call(...)
      end

      def self.users
        ::User.monitoring_activity.index_by(&:id)
      end

      def initialize(users: self.class.users, **)
        @users = users

        super()
      end

      def call
        @users.reject(...).map(...).whatever(...)
      end
   end
end

# ----------
describe ActivityMonitoring::Notifiers::UserEmail do
  let(:users) do
    {
      2 => :user2,
      3 => :user3,
      4 => :user4
    }
  end

    describe '#call' do
    context 'with data' do
      it 'return correct result' do
        expect(described_class.new(users: users).call).to eq(....)
      end
end

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

всё. тестируешь своё кастомное поведение. рельсу тестировать не надо
если надо потом обратно в базу сохранять делаешь еще одно DI - user_saver

class UserSaver
  def call(users)
    users.each(&:save!)
  end
end

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

с каким-нибудь AutoInject и контенерами половина бойлерплейта уйдет

И так неплохо выглядит, не надо менять бойлерплейт на мета-магию в которую не умеет ide, пожалуйста

а то получается что это не юнит-тесты бизнес логики
а интеграционные e2e тесты AR/Arel и бизнес логики