ruby-on-rails - rack_test - ruby capybara github

Rspec y organización de grandes archivos de especificaciones.

Question

Me preguntaba cómo otros organizan archivos de especificaciones grandes (especialmente para modelos) con muchos contextos y secciones organizadas en bloques de descripción para validaciones y otras especificaciones que se pueden agrupar de alguna manera significativa.

¿Mantienen todas las especificaciones relativas a un modelo en el mismo archivo de especificaciones para ese modelo, o se dividen en módulos de una forma u otra?

Nunca me he preocupado demasiado por esto hasta ahora, pero me pregunto qué hacen los demás, ya que no parece haber algún tipo de acuerdo en torno a una mejor práctica o algo así.

Tengo algunos archivos de especificaciones bastante grandes para algunos modelos que me gustaría organizar en archivos más pequeños, y hay poca o ninguna funcionalidad compartida entre los diferentes modelos, así que no estoy seguro de si los ejemplos compartidos serían la forma de hacerlo. (independientemente de la reutilización) o si hay alguna mejor manera. ¿Alguna sugerencia?

Gracias por adelantado.

Answer 1

Los contextos anidados pueden ayudarlo aquí, pero manténgalos poco profundos (por lo general, un nivel profundo). Hay dos variables a considerar en cada ejemplo: givens (estado de inicio) y qué método se está invocando. Puedes agrupar cosas por método o estado:

# by method
describe Stack do
describe "#push" do
it "adds an element to an empty stack"
it "adds an element to a non-empty stack"
end
describe "#pop" do
it "returns nil from an empty stack"
it "returns the last element of a non-empty stack"
it "removes the last element from a non-empty stack"
end
end
# by state
describe Stack do
context "when empty" do
specify "push adds an element"
specify "pop returns nil"
end
context "when not empty" do
specify "push adds an element"
specify "pop returns last element"
specify "pop removes last element"
end
end

He usado ambos enfoques y he visto que ambos funcionan realmente bien y muy mal. La clave de ambos enfoques es que los ejemplos cuentan una historia mientras lees de arriba a abajo. A medida que los requisitos evolucionan, esto significa que necesita revisar este archivo, al igual que lo hace con su código de implementación. Una forma fácil de verificar que la especificación tiene sentido es ejecutarlo con el formateador de documentación:

rspec stack_spec.rb --format documentation

Esto escupe todos los nombres en orden (siempre que no esté usando --order rand):

Stack
#push
adds an element to an empty stack
adds an element to a non-empty stack
#pop
returns nil from an empty stack
returns the last element of a non-empty stack
removes the last element from a non-empty stack

o

Stack
when empty
push adds an element
pop returns nil
when not empty
push adds an element
pop returns last element
pop removes last element

Una vez que vea esta salida, le resultará bastante claro si la organización que está utilizando tiene sentido o no.