Тестирование Rails с огурцом на сервере LDAP - PullRequest
4 голосов
/ 21 сентября 2009

Я пытаюсь написать несколько тестов на огурцы для моего приложения, которое использует Authlogic для аутентификации, но на самом деле хранит пользователей на сервере LDAP.

Приложение работает нормально, но когда я сталкиваюсь с проблемами, я пишу тесты для него (я знаю, я знаю, я должен был сначала написать тесты). Легко иметь тестовую базу данных, где данные очищается после каждого запуска, но не так просто с сервером LDAP.

Моя идея состояла в том, чтобы написать задачу rake (например, rake ldap: test: prepare) для обновления сервера ldap перед каждым запуском (или сделать его зависимым), но это кажется довольно трудоемким, когда я работаю над тестами (и делает автоматическое тестирование почти невозможным.)

Есть ли лучший способ сделать это? Существует ли поддельный сервер LDAP на основе ruby, к которому я могу привязаться с помощью предопределенных устройств? Есть ли какое-то еще более элегантное решение, о котором я не думаю? (не использовать LDAP не вариант.)

Ответы [ 5 ]

8 голосов
/ 10 августа 2011

Испытайте использование Ladle в качестве тестового сервера LDAP: «Разложите по порядку паровые подсказки облегченного доступа к каталогам (LDAP) для использования при тестировании с помощью rspec, cucumber или любой другой среды тестирования ruby».

https://github.com/NUBIC/ladle

3 голосов
/ 22 сентября 2009

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

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

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

Теперь это мой личный уклон, но если у вас нет модульных тестов, я бы посмотрел на RSpec. Если вам нравится англоязычный синтаксис Cucumber, RSpec определенно будет чувствовать себя похожим. Если вы уже несколько тестировались в Test :: Unit, я бы определенно предложил привлечь к вечеринке Ifa или, возможно, Context / Matchy (все они доступны на github), чтобы почувствовать RSpec в рамках Test :: Unit. *

2 голосов
/ 30 сентября 2009

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

Before do |scenario|
  puts "Cleaning Up LDAP Server"
  LdapConnect.new(:admin => true).clear_users!
end

А потом мой класс LdapConnect (поскольку многим моделям может потребоваться прикоснуться к серверу ldap, я могу просто обойти этот объект). Я использую гем ruby-net-ldap для взаимодействия с LDAP

class LdapConnect

  def initialize(params = {})
    ldap_config = YAML.load_file("#{RAILS_ROOT}/config/ldap.yml")[RAILS_ENV]
    ldap_options = params.merge({:encryption => :simple_tls})

    @ldap = Net::LDAP.new(ldap_options)
    @ldap.host = ldap_config["host"]
    @ldap.port = ldap_config["port"]
    @ldap.base = ldap_config["base"]
    @ldap.auth ldap_config["admin_user"], ldap_config["admin_password"] if params[:admin] 
  end

  def ldap
    @ldap
  end

  def clear_users!(base = "ou=people,dc=test,dc=com")
    raise "You should ONLY do this on the test enviornment! It will clear out all of the users in the LDAP server" if RAILS_ENV != "test"
    if @ldap.bind
      @ldap.search(:filter => "cn=*", :base => base) do |entry|
        @ldap.delete(:dn => entry.dn)
      end
    end
  end

end

Итак, моя функция огурца выглядит примерно так:

Feature: Check to make sure users can login
  In order to make sure users can login with the LDAP server
  As a user
  I want to make sure the user can login

  Background:
    Given I have the following users
    | email | password | user_class | first_name | last_name |
    | external@test.com | right_password | externalPerson | external | person |
    | internal@test.com | right_password | internalPerson | internal | person |
    | admin@test.com | right_password | adminPerson | admin | person |

  Scenario: Success Login Check
    Given I am logged in as "external@test.com" with password "right_password"
    Then I should be on the homepage

И наконец шаги

Given /^I have the following users$/ do |table|
  # table is a Cucumber::Ast::Table
  table.hashes.each do |hash|
    hash[:password_confirmation] == hash[:password] unless hash[:password_confirmation]
    User.create(hash)
  end
end

Given /^I am logged in as "([^\"]*)" with password "([^\"]*)"$/ do |email, password|
  visit login_url  
  fill_in "Email", :with => email  
  fill_in "Password", :with => password  
  click_button "Login" 
end
1 голос
/ 28 октября 2010

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

http://github.com/aanand/fakeldap http://rubygems.org/gems/fakeldap

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

0 голосов
/ 21 сентября 2009

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

Мэтт

...