Rails: сохранение обратных вызовов при создании подкласса IntegrationTest - PullRequest
Новая
       13

Rails: сохранение обратных вызовов при создании подкласса IntegrationTest

1 голос
/ 17 декабря 2010

У меня есть приложение Rails 3, которое использует субдомены для разделения разных вариантов использования. Обычные запросы webapp отправляются на www., Мобильный доступ идет на m., А запросы на API JSON направляются api ..

Мои интеграционные тесты попадают в эти же подразделения. Кроме того, все мои интеграционные тесты веб-приложений используют один и тот же код установки, мобильные интеграционные тесты используют другой код установки, а тесты API имеют свои собственные шаги установки. Я хочу реализовать несколько подклассов ActionDispatch::IntegrationTest, по одному для каждого «класса» интеграционных тестов, чтобы СУШИТЬ код: 

WebappIntegrationTest < ActionDispatch::IntegrationTest
MobileIntegrationTest < ActionDispatch::IntegrationTest
ApiIntegrationTest < ActionDispatch::IntegrationTest

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

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

class IntegrationTests::Webapp::AccountTest < WebappIntegrationTest
    def setup
        # ... do webapp account-specific setup ...
    end
end

Каждый тест в этом классе будет выполнять как настройку AccountTest, так и настройку WebappIntegrationTest. Специфичные для класса настройки должны быть необязательными, но специфичные для субдомена настройки должны выполняться каждый раз, независимо от того, определена ли специфическая для класса настройка.

Вот несколько подходов, которые я рассмотрел:

  1. Я не могу назвать оба метода установки «setup», и они оба запустятся ... установка AccountTest приведет к сбою установки WebappIntegrationTest.
  2. Я мог бы WebappIntegrationTest реализовать настройку, а затем объявить новый обратный вызов для AccountTest для реализации, назвать его "setup_extension" ... но я не хочу менять API: я хочу, чтобы новые разработчики быть в состоянии продолжить определение «настройки» в тестовых файлах, не обращая внимания на тот факт, что есть другая установка, называемая восходящей.
  3. Я рассмотрел использование alias_method_chain, чтобы вставить настройку WebappIntegrationTest в середине цепочки методов обратного вызова, но (a) я не смог заставить его работать (ruby threw и ошибка, сказав, что не удалось найти метод setup_with_x вообще) и (б) я полагаю, что в этом решении WebappIntegrationTest будет вызываться только в случае реализации настройки AccountTest, на которую я не могу рассчитывать для всех тестовых файлов (хотя я могу ошибаться в этом вопросе )

Надеюсь, это объяснение достаточно ясно ...

Любые мысли об элегантном способе перетаскивания общего кода установки в базовые классы для поддоменов (с кодом настройки, который выполняется для каждого теста этого типа) с сохранением API (возможность тестовых классов для опционально дополнительно реализовать собственный метод, который называется "setup")?

...