ruby-on-rails - tests - rspec rails tutorial

Pruebas de Rails Cucumber con un servidor LDAP

Question

Estoy intentando escribir algunas pruebas de pepino para mi aplicación que usa Authlogic para la autenticación, pero en realidad almacena usuarios en un servidor LDAP.

La aplicación parece funcionar bien, pero cuando tengo problemas es escribir pruebas para ello (lo sé, lo sé, debería haber escrito las pruebas primero). Es fácil tener una base de datos de pruebas donde los datos se borran después cada ejecución, pero no tan fácil con un servidor LDAP.

Mi idea era escribir una tarea de rake (como rake ldap: test: prepare) para actualizar el servidor ldap antes de cada ejecución (o convertirlo en una dependencia), pero eso parece consumir mucho tiempo cuando estoy trabajando en pruebas (y hace el autotest cerca imposible.)

¿Hay una mejor manera de hacer esto? ¿Existe un servidor LDAP falso basado en ruby ​​al que pueda enlazar con dispositivos predefinidos? ¿Hay alguna otra solución aún más elegante en la que no estoy pensando? (No usar LDAP no es una opción).

Answer 1

Realmente no es una respuesta, pero ... Estoy trabajando en un problema muy similar, probando la autenticación LDAP y el código de búsqueda con pepino. ¿Has buscado usar un trozo en tu prueba? Estaba pensando en anotar mis respuestas LDAP ... pero aún no he descubierto cómo hacerlo.

Mate

Answer 2

Entonces, en general, las pruebas de Cucumber son para pruebas de integración y aceptación. Siendo ese el caso, se supone que debe probar el sistema de extremo a extremo, por lo que también debería probar la integración de LDAP. Mi sugerencia, si puede cambiarlo, sería configurar otro servidor LDAP y hacer un volcado periódico de su servidor para configurarlo con los datos de prueba que necesite.

Sin embargo, diré que su primera idea de tener la dependencia que actualiza el LDB LDB antes de cada ejecución es la forma "correcta" de hacerlo. Se supone que las pruebas de integración / aceptación tardan mucho tiempo. Está probando la totalidad de la funcionalidad del sistema, no solo piezas pequeñas (unidades).

Pepino no es un marco de prueba de unidades, y no debe usarse de esa manera. Si su aplicación se rompió después de migrar a 2.3.4 porque no tenía pruebas, creo que debería ingresar allí y comenzar a escribir algunas pruebas unitarias ...

Ahora bien, este es mi sesgo personal, pero si no tienes pruebas de unidades en su lugar, echaría un vistazo a RSpec. Si te gusta la sintaxis similar al inglés de Cucumber, RSpec definitivamente se sentirá similar. Si ya eres un poco probado en Test :: Unit, definitivamente sugiero llevar Shoulda a la fiesta o posiblemente a Context / Matchy (todos los cuales están disponibles en github) para obtener la sensación RSpec dentro del marco Test :: Unit.

Answer 3

Finalmente, pude realizar básicamente la limpieza del servidor ldap antes de ejecutar cada escenario de pepino. Hice esto agregando un gancho en el pepino

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

Y luego mi clase LdapConnect (dado que es posible que varios modelos necesiten tocar el servidor ldap, puedo pasar este objeto). Estoy usando la gema ruby-net-ldap para la interacción 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

Por lo tanto, mi función de pepino se ve algo así como:

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 |
    | [email protected] | right_password | externalPerson | external | person |
    | [email protected] | right_password | internalPerson | internal | person |
    | [email protected] | right_password | adminPerson | admin | person |

  Scenario: Success Login Check
    Given I am logged in as "[email protected]" with password "right_password"
    Then I should be on the homepage

Y finalmente los pasos

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

Answer 4

He estado investigando esto por mí mismo, y me he topado con la gema Fakeldap, que está bastante debajo del radar.

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

Puedo agregar a esta respuesta con un poco de experiencia después de haberla usado.

Answer 5

Haga una prueba usando Ladle como servidor LDAP de prueba: "Descarte los platos al vapor del acceso ligero al directorio (LDAP) para usarlos en pruebas con rspec, pepino o cualquier otro marco de prueba de ruby".

https://github.com/NUBIC/ladle