ruby on rails - run - ¿Qué se considera una buena especificación? Ejemplos de Rspec para principiantes.

ruby on rails selenium

Question

¿Qué se considera una especificación sólida?

Esto es lo que encuentro muy abstracto acerca de las pruebas. Me interesaría la respuesta a esto en modelos, controladores y cualquier otra cosa que se pueda probar. Sería genial tener una especificación para una especificación, ¿sabes a qué me refiero?

Una especificación del modelo debe (en orden de prioridad y relevancia):

1. ¿Prueba todos los métodos?
2. Prueba de matriz de errores?
3. Prueba CRUD (y como)?
4. ¿Qué más?

Una especificación de controlador / vista debe (en orden de prioridad / relevancia):

1. Rellene el espacio en blanco ...
2. ?

Sería genial expandir esta lista de lo que una especificación debe y no debe contener.

También me gustaría compilar una lista de trucos y sugerencias también. Por ejemplo:

La palabra clave "debería" es algo redundante.

Ejemplo:

esta:

it "should be invalid without a firstname"

sería mejor como:

it "is invalid without a firstname"

Otro truco más, use esperar en lugar de lambda para facilitar la lectura:

lambda { ... }.should be_valid

es más legible como:

expect { ... }.should be_valid

Estoy compilando una lista de artículos útiles sobre cómo empezar y los compartiré en esta publicación a medida que vayan apareciendo. Aquí hay algunos que me parecen particularmente útiles a partir de ahora. (Siéntete libre de publicar el tuyo y lo agregaré si parece útil).

http://everydayrails.com/2012/03/19/testing-series-rspec-models-factory-girl.html http://nelvindriz.tumblr.com/post/835494714/rspec-best-practices

Sería genial tener una lista de proyectos donde las pruebas se implementen bien. Dado que rspec es tan legible (al menos eso es lo que dice todo el mundo), sería fantástico obtener una lista de enlaces a proyectos que tengan especificaciones excelentes para leer.

"Consulte las especificaciones de Mongoid para ver un ejemplo de buenas especificaciones". - @yfeldblum (ver respuesta abajo)

En línea, encontrarás muchos artículos que describen escenarios poco realistas sobre cómo probar cosas básicas, pero más allá de eso, estás por tu cuenta. Si escribiera un artículo sobre este tema, solo enlazaría mis pruebas (en github, por ejemplo), luego anotaré una o algunas de esas especificaciones ... esta parece ser la mejor manera de escribir un artículo sobre rspec. en mi opinión. Lo haría yo mismo, pero no estoy del todo allí todavía.

Si vota para cerrar esto, está bien, solo intente dejar un comentario o sugerencia sobre a dónde cree que pertenecerá esta publicación. ¡Gracias!

Answer 1

Cuando está escribiendo sus pruebas de controlador, desea cubrir con pruebas todas sus acciones en su controlador.

Ejemplo de cómo deberían ser las pruebas para las acciones del controlador:

describe "Stories" do
describe "GET stories#index" do
context "when the user is an admin" do
it "should list titles of all stories"
end
context "when the user is not an admin" do
it "should list titles of users own stories" do
end
end
describe "GET stories#show" do
it "should render stories#show template" do
end
end
describe "GET stories#new" do
it "should render stories#new template" do
end
end
describe "POST stories#create" do
context "with valid attributes" do
it "should save the new story in the database"
it "should redirect to the stories#index page"
end
context "with invalid attributes" do
it "should not save the new story in the database"
it "should render stories#new template"
end
end
describe "DELETE stories#delete" do
it "should delete the story from the database"
it "should redirect to the stories#index page"
end
end

Puede encontrar más información sobre las pruebas de los controladores aquí .

Answer 2

Esta es realmente una buena pregunta porque cuando empecé con los casos de prueba, no estaba seguro de lo que se considera un buen caso de prueba. Aquí hay algunas cosas que puedes seguir. Esta lista no es mía; pero compilado de algunas fuentes más algunas de mis adiciones.

Describir los métodos.

Al describir métodos, es una buena práctica describir su método como: describir "#admin?" etc. "." es un prefijo para el método de clase y "#" es un prefijo para los métodos de instancia.

Una afirmación por caso de prueba

Asegúrese de tener una sola afirmación por caso de prueba. Esto asegura que sus casos de prueba sean limpios y fáciles de entender; ¿Cuál es el punto de los casos de prueba, no es así? :)

Evite guardar datos en db

Puede crear objetos dinámicamente y evitar guardar los datos en db. Aunque puede limpiar la base de datos antes de cada caso de prueba, "no guardar" acelerará los casos de prueba en gran medida.

@ user.build (: something) en lugar de @ user.create (: something)

Casos perimetrales e inválidos

Esto no es específico de Rspec, pero es importante asegurarse de que los casos de borde estén cubiertos en las pruebas. Esto ayuda mucho más adelante cuando su proyecto crezca y sea fácil de mantener.

contexto

A mí, personalmente, me gusta mucho esto en Rspec y, de hecho, uso demasiado los contextos. Usar contextos con condiciones ayuda a compartimentar sus casos de prueba. Aquí hay un ejemplo:

# Avoid
it "should have 200 status code if user is logged in" do
response.should respond_with 200
end
it "should have 401 status code if user is not logged in" do
response.should respond_with 401
end
# Use
context "when user is logged in" do
it { should respond_with 200 }
end
context "when user is logged out" do
it { should respond_with 401 }
end

Usando sujeto

Cuando tiene muchos casos de prueba relacionados con la misma cosa, puede usar subject () para asegurarse de que no se repite.

# Avoid
it { assigns(:user).should be_valid }
it { assigns(:user).should_not be_dumb }
it { assigns(:user).should be_awesome }
# Use
subject { assigns("user") }
it { should be_valid }
it { should_not be_dumb }
it { should be_awesome }

Aquí hay algunas cosas que trato de seguir cuando escribo casos de prueba. Estoy seguro de que hay muchas más cosas que pueden mejorar los casos de prueba de Rspec. Pero esto debería ser suficiente para comenzar y escribir impresionantes casos de prueba.

Answer 3

Estoy siguiendo un tutorial para aprender Ruby on Rails, y está enseñando Rspec como parte del desarrollo basado en pruebas. El flujo aquí es escribir una prueba que falla, escribir código para pasar la prueba y luego pasar la prueba. La razón parece ser que al hacer esto, comenzando con una prueba fallida, puede estar bastante seguro de que su código hace lo que espera. Así que supongo que una buena especificación es aquella que garantiza que su código haga lo que se supone que debe hacer. Sin embargo, hasta ahora no he recogido ninguna regla práctica del tutorial como han escrito otros carteles.

Aquí está el enlace: http://ruby.railstutorial.org/

Answer 4

Ver las especificaciones de Mongoid para un ejemplo de buenas especificaciones.

• Tenga exactamente una aserción por ejemplo. No afirmes dos cosas en el mismo ejemplo. Un ejemplo es el bloque que se le pasa, its , o specify .