Rspec & large spec organization

Question

Me preguntaba cómo otros organizan grandes archivos de especificaciones (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.

¿Ustedes 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 ha importado demasiado 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 buena práctica o tal.

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 en diferentes modelos, así que no estoy seguro de si los ejemplos compartidos serían el camino para hacer esto (independientemente de la reutilización) o si hay alguna forma mejor. ¿Alguna sugerencia?

Gracias de antemano.

Answer 1

Los contextos anidados pueden ayudarlo aquí, pero manténgalo superficial (generalmente un nivel profundo). Hay dos variables a considerar en cada ejemplo: dadas (estado inicial) y qué método se está invocando. Puede agrupar cosas por el método o estatal:

# 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 les visto ambos trabajan muy bien y muy mal. La clave de ambos enfoques es que los ejemplos cuentan una historia mientras lees de arriba abajo. A medida que evolucionan los requisitos, esto significa que debe revisar este archivo, tal como lo hace con su código de implementación. Una manera fácil de comprobar que la especificación tiene sentido es para ejecutarlo con el formateador documentación:

rspec stack_spec.rb --format documentation 

Este escupe todos los nombres en orden (siempre y cuando no se esté usando rand --order):

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, que va a ser bastante claro para que si la organización está utilizando tiene sentido o no.