Интеграционные тесты для страниц единого входа - PullRequest
4 голосов
/ 12 июля 2011

Как вы тестируете страницы с единой регистрацией (SSO) во время интеграционных тестов (например, с помощью caybara или cucumber)?Для обычного входа в систему вы должны написать метод, который посещает страницу входа в систему, заполняет форму и отправляет ее.Это немного сложно, если форма входа в систему приходит с внешнего сервера единого входа, такого как Shibboleth или OpenAM / OpenSSO.Как можно написать интеграционные тесты для страниц, защищенных SSO?

Аналогичная проблема - интеграционное тестирование с отдельным поисковым сервером (Solr или Sphinx).Вы, вероятно, решили бы это, используя какую-то форму насмешек или заглушек.Может кто-нибудь привести хороший пример, как издеваться или заглушить SSO для огурца или капибары?Если это слишком сложно, то будет полезен и сопоставимый пример для поискового сервера.

1 Ответ

7 голосов
/ 26 июля 2011

Интеграционное тестирование приложения SSO является частный случай более общей проблемы: тестирование распределенные приложения. Это сложно проблема и там, похоже, не волшебство пуля за это. Есть разные способы совмещения набор разных серверов или сервисов и их тестирование в целом. Две крайности

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

б) Написать интеграционный тест для каждого компонента, относиться к нему как к черному ящику и недостающие связи издевательствами и заглушками. На практике этот подход более распространен для модульное тестирование, каждый пишет тесты для каждого Слой MVC: модель, вид и контроллер (вид и контроллер часто вместе).

В обоих случаях вы не учли разорванные связи. В принципе один должен проверить для каждого внешнего сервера / службы следующие возможности

  • снижается
  • работает и ведет себя хорошо
  • вверх и отвечает неправильно
  • , но вы отправили неверные данные

По сути, тестирование распределенных приложений затруднено. Это одна из причин, по которой распределенные приложения трудно разрабатывать . Чем больше частей и серверов у распределенного приложения, тем сложнее настроить многие полноценные среды, такие как производство, подготовка, тестирование и разработка. Чем больше система, тем сложнее интеграционное тестирование становится. На практике, каждый использует первый подход и создает небольшой но полная версия всего приложения. Типичная простая настройка: сервер приложений + сервер БД + сервер поиска. На вашей машине разработки, вы бы имели две разные версии полной системы:

  • Один сервер БД с несколькими базами данных (разработка и тестирование)
  • Один поисковый сервер с несколькими индексами (разработка и тестирование)

Общие плагины Ruby для поисковых серверов (Thinking Sphinx for Sphinx или Sunspot для Solr) поддержка огурцов и интеграция тесты. Они «включают» поисковый сервер для определенных частей ваши тесты. Для кода, который не использует поисковый сервер, они «заглушают» сервер или макетируют соединение, чтобы избежать ненужного индексации.

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

  before :each do
    @current_user = Factory(:user)
    controller.stub!(:current_user).and_return(@current_user)
    controller.stub!(:logged_in?).and_return(:true)
  end

Это также работает для тестов помощника и просмотра, но не для запроса RSpec или интеграционных тестов.

Для тестов на огурцы можно заглушки сервер поиска, заменив соединение на поисковый сервер с заглушкой (для Sunspot и Решить это можно путем замены Sunspot.session , который инкапсулирует соединение с Solr).

Все это звучит хорошо, к сожалению, это немного трудно перенести это решение на сервер единого входа. Типичный минимальный установка будет Сервер приложений + Сервер БД + Сервер SSO. Полный тест интеграции означает, что нам нужно настроить один SSO-сервер с несколько пользовательских хранилищ данных (разработка и тестирование). Настроить SSO-сервер уже достаточно сложно, настройка сервера единого входа с несколькими пользовательскими данными магазины, вероятно, не очень хорошая идея.

Одним из возможных решений проблемы может быть где-то в направление Fakeweb . FakeWeb - это библиотека Ruby, написанная Блейн Кук за фальсификацию веб-запросов. Это позволяет вам отделить ваша тестовая среда из живых сервисов. Поддельный ответ сервера SSO, к сожалению, немного сложно.

Другое возможное решение, которое я в итоге использовал, - это использование фальшивого логина , т.е.добавить фальшивый метод входа в систему, который можно вызвать в интеграционном тесте.Этот фальшивый логин - это динамический метод, добавляемый только во время теста (через форму «мартышки»).Это немного грязно, но, похоже, работает.

...