2011-06-26 22 views
25

Soy nuevo en la prueba de aplicaciones web Rails y RSpec. Trabajo con código heredado y necesito agregar pruebas. Entonces, ¿cuál es la mejor manera de probar los buscadores y los ámbitos nombrados con RSpec?Rieles: probando ámbitos con nombre con RSpec

Encuentro en Google algunos enfoques, pero no son ideales. Por ejemplo:

http://paulsturgess.co.uk/articles/show/93-using-rspec-to-test-a-named_scope-in-ruby-on-rails

it "excludes users that are not active" do 
    @user = Factory(:user, :active => false) 
    User.active.should_not include(@user) 
end 

o

http://h1labs.com/notebook/2008/8/21/testing-named-scope-with-rspec

it "should have a published named scope that returns ..." do 
    Post.published.proxy_options.should == {:conditions => {:published => true}} 
end 

me parece mejor enfoque (en mi humilde opinión) en "tren de prueba recetas":

should_match_find_method :active_only { :active == true } 

donde should_match_find_method método de ayuda personalizada

+2

pruebas de alcance son realmente empíricas y me quedo con el primer método que expone aquí – apneadiving

+4

Estoy de acuerdo. ¿Qué pasa con el primer acercamiento? Especifica el comportamiento verdadero en lugar de examinar (en realidad solo reescribir) los parámetros de configuración posiblemente defectuosos. –

+0

@RobDavis "parámetros de configuración posiblemente defectuosos" +1 –

Respuesta

29

El creador de RSpec ha blogueado recientemente cree que Validations are behavior, associations are structure. En otras palabras, encuentra que las asociaciones (y los ámbitos) no deben probarse necesariamente de manera directa. Las pruebas para estos seguirán del comportamiento que desee.

En otras palabras, la sabiduría actual es que no hay necesidad de probar cada alcance directamente, ya que cubrirá estas asociaciones probando el comportamiento de su aplicación.

+32

No menciona nada acerca de los ámbitos en esa publicación; sin embargo, ¿por qué los agrupas con asociaciones? Los ámbitos pueden ser mucho más complicados y propensos a errores que las asociaciones, y creo que deberían probarse. Dado que invocaste al poderoso creador, [aquí] (http://groups.google.com/group/rspec/browse_thread/thread/6706c3f2cceef97f) sugiere que si un alcance cae bajo el paraguas del comportamiento (y si no lo hace) , ¿por qué está allí?), entonces debe especificarse. –

+3

No estoy en desacuerdo con que los ámbitos no deben ser probados. Definitivamente deberían. Simplemente no directamente; la prueba de los ámbitos debe realizarse comprobando el comportamiento de la aplicación.Veo que los ámbitos son similares a las asociaciones, ya que ambos pueden tener opciones complejas como uniones, modelos incluidos, donde/agrupar por/tener etc. En cualquier caso, esto es lo que tiene sentido para mí. –

0

El problema con el primer enfoque es que realmente consulta la base de datos. Es lento e innecesario. Si no te importa, puedes utilizar el primer enfoque de forma segura. El segundo enfoque es rápido y claro, así que lo recomendaría.

+2

¿Está seguro de que la consulta no es necesaria en una especificación de modelo? Puedo entender que no lo haga en un controlador o ver una especificación - simular y guardarla. Pero creo que quieres probar el modelo y su relación con la base de datos aquí. – jaydel

+0

IMO no es necesario cuando se prueban ámbitos con nombre. Debe tener muchas otras pruebas que realmente lean de la base de datos. –

+14

Los ámbitos son un área donde sin duda tiene sentido consultar la base de datos para buscar objetos reales. Favorezco las burlas donde sea apropiado, pero solo los ámbitos más simples funcionarán con los simulacros. Una vez que comiences a unirte o agrupar, se romperán, y yo he convertido en una regla probar los ámbitos en una verdadera tienda de respaldo. Los evaluadores basados ​​en configuración como el segundo y el tercer ejemplo son propensos a errores, en mi humilde opinión. Es decir, es muy probable que tengan los mismos errores que tu código. –

Cuestiones relacionadas