Ещё *args аллоцирует массив, много чести для такого утилитарного модуля, ещё и на каждый вызов. В 2.7 есть ..., но этот код для любой поддерживаемой версии, даже define_method я вызвал через send

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

может, лучше reentrant lock 🤔

важно понимать, что глобальный мутабельный апи это плохо ;)

это тоже :)

Народ, кто использует rspec без database_cleaner. Тип в спеках работаем только с тем, что генерим, и не заботимся об очистке БД из-за перфоманса. Какие есть подводные камни у такого подхода?

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

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

упс, да. мьютекс получился на все инстансы =\
просто мне не нравится что этот мьютекс протекает в класс и доступен там как instance variable
тогда надо делать еще одну обертку типа

module Sync
  def initialize(*)
    singleton_class.prepend SynchronizedAccess.new
    super
  end
end

class Foo
  include Sync
end

заодно починим наследование, потому что в обоих случая class Bar < Foo; def foo; end end работать не будет

еще я жутко не люблю _eval и _exec и стараюсь от них избавиться
хотя define_method по сути тоже eval, но это необходимое зло, и если бы было можно - с радостью бы избавился

можно, но если у тебя будет какой-нибудь домен статистики,  и там будет юнит калькулирующий глобальную статистику - то будет уже не очень

module Sync
  def initialize(*)
    singleton_class.prepend SynchronizedAccess.new
    super
  end
end

class Foo
  include Sync
end

лучше спокойно написать свой лок и юзать его явно

если беспокоит большой сетап и «данные исключительно для конкретного спека», можешь использовать стандартные фикстурки — они достаточно быстрые — и стартовать БД транзакцию перед выполнением каждого отдельного теста, а не всего суита

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

но если оставите артефакт в виде статьи / доклада — будет огонь

тут вся история вокруг того как не писать свой лок, а сделать хелпер =)

да нужно постоянно смотреть, что ты именно со своими данными работаешь. И не можешь использовать условные User.all потому что там будет куча не тобой созданных юзеров.

Идея: каждому тесту своя база, все будет моментально!

С учетом того что люди для локальной разработки у себя k8s кластер поднимают, не удивлюсь если кто-то сделает что-то подобное=)

Почему не используете транзакции? Быстро и без глобального состояния.

Архитектурные технические решения принимаю не я. Я бы заюзал транзакции. Теперь я хочу понять с чем придется столкнуться, и как миниммизировать неудобства, мб кто прошел через это и имеет гештальт.

есть статья в которой описывается как за счет транзакций избавиться от глобоального состояния в тестах?

Схема такая - после сборки на CI и CD, собирается докер образ с заполненной бд, который юзается как бд для дев и для тест. И в тестах дополнительно создаются данные в каждой спеке, ты с ними работаешь, но не удаляешь database_cleanerом

Был у кого похожий опыт, и если был, то как справлялись)